ис. Лекция 3. Структурный и объектно-ориентированный подходы к разра. Структурный и объектноориентированный подходы к разработке ис
 Скачать 1.04 Mb.
|
|
Структурный и объектно-ориентированный подходы к разработке ИС План лекции: 1. Структурный подход 1.1 Методы структурного анализа предметной области - Схема Захмана для бизнес-моделирования - Схема деятельности компании в нотации Йордана-ДеМарко - Схема деятельности компании в нотации Гэйна – Сарсона - Диаграмма ER-типов 2. Объектно-ориентированные методы разработки ИС 1. Структурный подход Структурный подход к разработке является классическим и предполагает последовательную реализацию следующих этапов разработки: • анализа предметной области, • проектирования, • создания программных модулей, • объединения модулей в единую систему, • тестирования, • внедрения. Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь, делятся на подфункции, подразделяемые на задачи и т. д. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. 1.1 Методы структурного анализа предметной области ИС должно предшествовать выяснение вопроса о составе функций, возлагаемых на систему, и тех свойствах, которыми система должна обладать, чтобы удовлетворять потребности пользователей. Выяснение этого вопроса оформляется в виде требований к ИС. Базовая идея схемы Захмана заключается в том, что деятельность любой организации можно описать на основе ответов на шесть простых вопросов (зачем, кто, что, как, где и когда?), выясняемых на нескольких уровнях и определяемых шестью сторонами рассмотрения предметной области: зачем мотивация– цели организации и правила, по которым она работает кто люди– предприятия, организации, с которыми сотрудничает организация, собственный персонал и функциональные подразделения что данные – сущности и сведения, составляющее информационное пространство организации как функции – выполняемые организацией и ее подразделениями процессы и операции над данными где место – географическое распределение элементов организации и связи между географически разделенными элементами когда время – временные интервалы и события, существенные для деятельности организации Схема Захмана для бизнес-моделирования Количество уровней рассмотрения предметной области определяет степень детализации формального представления этой области. • Первый уровень – «Контекст» – это уровень организации в целом. Он описывает основные виды деятельности организации, ее цели и планы, связи с внешним миром и перспективы развития. • Второй уровень – «Модель бизнеса» –шестисторонне описывает внешнее(архитектурное) представление деятельности предприятия, уточняя соответствующие описания первого уровня. Все последующие уровни все более конкретизируют формальное представление предметной области, доводя его до описаний (спецификаций) и программного кода. Схема деятельности компании в нотации Йордана–ДЕМАРКО Графические схемы как средство моделирования используются очень активно и позволяют повысить наглядность представления проблемных сведений. Дополненные текстовыми пояснениями схемы образуют наглядные, четкие и достаточно полные описания моделируемых процессов и объектов. Для описания поведения сложных систем и деятельности крупных организаций могут использоваться диаграммы потоков данных(Data Flow Diagrams (DFD)). Эти диаграммы содержат четыре вида графических элементов: 1) процессы – процедуры преобразования и (или) обработки данных; 2) хранилища данных; 3) сущности – объекты предметной области; 4) потоки данных между процессами, хранилищами и сущностями. Для указанных элементов DFD используются нотации Йордана – ДЕМАРКО и Гэйна–Сарсона, предложенные в 1979 г. В нотации Йордана – ДЕМАРКО элементы DFD изображаются следующими фигурами: - процессы – окружностями; - хранилища – двумя горизонтальными параллельными линиями; - сущности – прямоугольниками; - потоки данных – стрелками. Схема деятельности компании в нотации Гэйна – Сарсона В нотации Гэйна – Сарсона элементы DFD изображаются следующими фигурами: - процессы – прямоугольниками со скругленными углами; - хранилища – вытянутыми горизонтально прямоугольниками без правого ребра; - сущности – прямоугольниками с тенью; - потоки данных – стрелками Диаграмма ER-типов В качестве формального описания структуры данных в структурном анализе используются диаграммы сущностей и связей (Entity-Relationship Diagrams (ERD)), называемые диаграммами ER-типов. Объектно-ориентированные методы разработки ИС Объектно-ориентированные методы разработки основаны на объектно-ориентированной концепции или, как часто говорят, парадигме. Парадигма – теория (или модель, тип постановки проблемы), принятая в качестве образца решения исследовательских задач. Объектно-ориентированная парадигма – способ описания приложений, при котором приложение предварительно делится на множество маленьких кусочков или объектов относительно независимых друг от друга. Готовое приложение можно затем создать, сложив эти объекты вместе. Преимуществом такого решения является возможность разработки компонентов только один раз с последующим многократным их использованием для создания абсолютно различных по назначению систем. Снижение риска в объектно-ориентированной технологии достигается за счет реализации технологии итерационной разработки, когда используется спиральная модель жизненного цикла разработки. Разработка состоит из ряда этапов (итераций), которые в дальнейшем приводят к созданию информационной системы. Каждая итерация может приводить к созданию фрагмента или новой версии и включает все необходимые этапы: этапы выработки требований, анализа, проектирования, реализации и тестирования. Поскольку тестирование проводится на каждой итерации, риск снижается уже на начальных этапах жизненного цикла. Эти преимущества могут быть реализованы только при правильном проектировании систем в соответствии с принципами инкапсуляции, наследования и полиформизма. В настоящее время основой объектно-ориентированных методологий является Unified Modeling Language (UML) – унифицированный язык графического описания объектных моделей, созданный для разработки ПО и успешно применяемый при проектировании ИС. Одной из наиболее популярных объектно-ориентированных методологий проектирования программного обеспечения является Rational Unified Process (RUP) – методология, предложенная компанией Rational Software. В объектно-ориентированной методологии проектирования вместо диаграмм потоков данных используются диаграммы прецедентов(вариантов использования), а вместо диаграмм сущностей и связей – диаграммы классов. Диаграммы вариантов использования информационно беднее соответствующих диаграмм потоков данных, потому что в них процессы и хранилища объединяются в единые конструкции, называемые вариантами использования. Вариант использования – это описание последовательности действий, выполняемых системой в ответ на внешние воздействия. • Некоторые диаграммы UML создаются в процессе разработки ИС несколько раз: 1) как средство представления предметной области во время ее обследования и выяснения потребности заказчика – это бизнес-диаграммы, создаваемые на фазе, называемой: «Анализ», этап «Обследование» (базовая терминология SADT); «Формирование требований (терминология ГОСТ 34.601–90); «Начало», процесс «Бизнес-моделирование» (терминология RUP); 2) как средство представление требований, предъявляемых к системе; диаграммы этого уровня могут использоваться в ТЭО – это системные варианты тех же диаграмм, создаваемые на фазе, называемой «Анализ», этап «Изложение требований» (базовая терминология SADT «Разработка концепции» (терминология ГОСТ 34.601–90); «Уточнение», процесс «Управление требованиями» (терминология RUP); 3) как средство представления проектных решений – это тоже системные варианты диаграмм, создаваемые в последующих фазах ЖЦ; 4) как средство представления уточненных требований, предъявляемых к системе; это системные диаграммы, которые могут использоваться в начале всех фаз ЖЦ, но, в первую очередь, они используются на следующих фазах: «Проектирование» (базовая терминология SADT«Техническое задание» (терминология ГОСТ 34.601–90); «Уточнение», процесс «Анализ и проектирование» (терминология RUP). Для того чтобы правильно сформулировать требования к ИС, необходимо четкое понимание контекста, в котором будет работать будущая система. Для достижения этого понимания создаются модель предметной области и (или) бизнес-модель. Эти две модели представляют два подхода к одному и тому же вопросу: первая модель призвана, в первую очередь, отразить информационный аспект, а вторая – процессный аспект того предприятия (организации, учреждения), для которого создается ИС. Иногда создается что-то одно либо модель предметной области, либо бизнес-модель. На этапе «Обследование» фазы «Анализ» в большинстве случаев, оказывается достаточным построение следующих UML-описаний: 1) диаграмма бизнес-прецедентов; 2) диаграммы бизнес-деятельностей (по одной на каждый бизнес-прецедент. Перечисленные диаграммы образуют проектный минимум. При тщательной проработке предметной области они могут дополняться диаграммами бизнес-коммуникаций и (или) бизнес-последовательностей. Указанные диаграммы семантически эквивалентны, отличаются только формой представления информации. В совокупности указанные диаграммы образуют бизнес-модель предприятия или модель анализа предметной области. UML-модель анализа предметной области На стадии «Изложение требований» фазы «Анализ» строятся те же диаграммы, что и на этапе «Исследование», но уже не бизнес-варианты, а системные варианты этих диаграмм, и они представляют собой модельно (схематически) представленные требования к создаваемой ИС. Однако эти требования носят процедурный (операционный) характер. Информационная составляющая в них представлена весьма ограниченно. Для устранения указанного упущения следует завершить фазу анализа построением предварительного варианта диаграммы классов (Class diagram) как заменитель ER-диаграмм, применяемых в структурной методологии. Совокупность свойств классов, образует достаточно четкое и полное требование к информационной составляющей создаваемой ИС. UML-модель требований к создаваемой ИС (логическая модель ИС) Диаграмма бизнес-прецедентов. Диаграмма бизнес-прецедентовво многом аналогична обычной (системной) диаграмме прецедентов, но имеются и существенные отличия: - вместо простых акторов используются бизнес-акторы (бизнес- актанты); - вместо системных прецедентов используются бизнес-прецеденты; - в системных диаграммах прецеденты – это действия, выполняемые внутри ИС, т. е. это информационно-вычислительные процессы, выполняемые либо компьютером, либо автоматом, либо человеком во взаимодействии с компьютером; действия в бизнес-прецедентах– это реальные физические деловые процессы, выполняемые людьми и (очень часто) без использования компьютера. Диаграммы бизнес-деятельности. Диаграммы бизнес- деятельности должны составляться для каждого бизнес- прецедента, представленного на диаграмме бизнес- прецедентов. Диаграмма бизнес-деятельности, реализующая прецедент «Продажа товара» Диаграмма бизнес-последовательности. Традиционно рекомендуется дополнять диаграмму бизнес-прецедентов диаграммой бизнес-объектов, на которой отображаются бизнес-работники и бизнес-сущности, соединенные друг с другом прямыми линиями – связями. Однако эта диаграмма малоинформативна. Более содержательными являются диаграммы бизнес-взаимодействия: бизнес-последовательности и бизнес- коммуникации, которые являются удобным графическим средством демонстрации бизнес-сценариев – конкретных цепочек действий при выполнении бизнес- прецедента. Конкретная цепочка действий имеет также компактное название – «сценарий бизнес- прецедента». При построении диаграмм бизнес-последовательности бизнес- коммуникаций отображается взаимодействие бизнес-работников и бизнес- сущностей – всё этобизнес-объекты. Составляющими диаграмм бизнес-последовательности и бизнес-коммуникации в общем случае являются объекты со специальными стереотипами поведения: бизнес-актор; бизнес-работник; бизнес-сущность. Обратим внимание на то, что бизнес-акторы фигурируют и в модели прецедентов, и в моделях коммуникации и последовательности. Диаграмма бизнес-последовательности, демонстрирующая один из сценариев бизнес-прецедента «Оформить продажу» Диаграмма прецедентов. После построения бизнес-модели предприятия переходят к изложению требований к создаваемой ИС. Для этого, в частности, создается системный вариант диаграммы прецедентов. Очень часто этот вариант не имеет кардинальных отличий от построенной ранее диаграммы бизнес-прецедентов, поскольку все составляющие бизнес-процесса предприятия получают воплощение в подсистемах ИС. Для каждого прецедента создается детализирующая этот прецедент диаграмма деятельности или автомата (в зависимости от специфики процессов и задач предметной области). Так же, как и при создании бизнес-модели, для каждого прецедента создается одна или несколько диаграмм последовательности и (или) диаграмм коммуникации. Каждая из этих диаграмм представляет собой конкретный сценарий развития событий при выполнении действий прецедента, т. е. один из протоколов этого прецедента. Диаграмма классов. На стадии «Изложение требований» фазы«Анализ» ЖЦ ИС создается предварительный вариант диаграммы классов (Class diagram) как заменитель ER-диаграмм, применяемых в структурной методологии. Диаграмма классов во многом аналогична – она также определяет носители предметной информации и взаимосвязи между ними. Однако носители называются уже не сущностями, а классами. В отличие от сущностей классы содержат не только данные, называемые атрибутами, или полями, но и процедуры решения задач – подпрограммы, называемые операциями или методами. Диаграмма классов для предметной области «Магазин» Для каждого класса должно быть указано: 1) какой физической сущности соответствует данный класс; 2) почему выбран именно такой состав атрибутов; 3) почему выбран именно такой состав операций; 4) какую функцию реализует каждая операция. |