Моделирование требований к системе 29 icon

Моделирование требований к системе 29


2 чел. помогло.

Смотрите также:
Моделирование бизнес-процессов спецификация требований на основе структурного подхода...
Лекция: Этапы проектирования ис с применением uml: Основные типы uml-диаграмм...
Реферат отчёта по нир на тему: «Разработка требований к системе отраслевых показателей...
Формулирование и анализ требований 1 Определение требований к системе 2 Пользовательские...
Формулирование и анализ требований 1 Определение требований к системе 2 Пользовательские...
Уточнение требований к системе 6 Архитектура системы 8...
Программа вступительного экзамена в магистратуру по направлению...
Руководство по системе pc4020...
“Компьютерное моделирование работы схемы усилителя”...
К минимуму содержания и уровню требований к специалистам для присвоения дополнительной...
Учебная программа. Наименование тем, их содержание...
К минимуму содержания и уровню требований к специалистам для присвоения дополнительной...



страницы: 1   2   3   4   5   6   7   8   9   ...   13
вернуться в начало
скачать
^

Рабочие процессы



Рациональный Унифицированный Процесс состоит из девяти рабочих процессов:

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

  • разработка требований - описывается основанный на прецедентах метод постановки требований;

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

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

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

  • развертывание - охватывает конфигурирование поставляемой системы;

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

  • управление проектом - описывает разные стратегии работы с итеративным процессом;

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


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

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

Артефакты



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

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

Модели



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

модель бизнес-процессов - формализует абстракцию организации;

модель предметной области - формализует контекст системы;

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

аналитическая модель (необязательная) - формализует идею проекта;

проектная модель - формализует словарь предметной области и области решения;

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

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

модель реализации - описывает части, из которых собирается физическая система;

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


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

^

Другие артефакты



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

  • группа требований - описывает, что система должна делать;

  • группа проектирования - описывает, как система должна быть построена;

  • группа реализации - описывает сборку разработанных программных компонентов;

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


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

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

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

ЛЕКЦИЯ 4. Анализ и проектирование. Стадия анализа




Предварительные замечания



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

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

В реальной жизни программные проекты чаще всего достаточно сложны, и их декомпозиция (по принципу "разделяй и властвуй") - это основная и, наверное, единственная стратегия борьбы со сложностью. Она состоит в разбиении проблемы на мелкие управляемые элементы. До появления объектно-ориентированного подхода во времена господства парадигмы структурного программирования наиболее популярной методологией декомпозиции являлись структурный анализ и проектирование (structured analysis and design). Этот подход заключается в декомпозиции задачи на функции или процессы, приводящий к созданию иерархии процессов и подпроцессов. Существовали и существуют и другие методы декомпозиции. В следующем разделе мы рассмотрим наиболее известные и часто применяемые методики анализа, позволяющие минимизировать риски и решать ключевые проблемы, возникающие на различных этапах жизненного цикла.

^

Стадия анализа




Стандарты семейства IDEF



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

  • IDEF0 - стандарт функционального моделирования (принят).

  • IDEF1 (X) - стандарт информационного моделирования (принят), хорошо известен еще и под названием "ER- диаграммы".

  • IDEF2 - стандарт математического моделирования (не принят). Не принятие стандарта математического моделирования было вполне естественным, так как при реализации математической модели приходилось либо жертвовать ее точностью, либо ... самой возможностью что-то моделировать, ввиду чего никогда нельзя было с полной уверенностью говорить о "соответствии математической модели функциональной", разработанной в стандарте IDEF 0. Тем не менее, существуют программные продукты, которые позволяют проводить математическое моделирование по функциональному описанию в стандарте IDEF0.

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


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

  • DFD "Data flow diagram", "диаграммы потоков данных" - широко распространенная методология моделирования процессо-ориентированного типа.

  • "Моделирование в терминах системы" - одной из существенных проблем при использовании "универсальных" методологий моделирования является дальнейшее использование результатов в практической работе, например при внедрении или создании корпоративной информационной системы. Часто оказывается (особенно до создания методологии IDEF 3), что применить результаты длительной работы достаточно сложно. Поэтому неудивительно, что все крупнейшие поставщики интегрированных программных систем озаботились созданием специализированных систем моделирования, адекватных применяемой системе. Наиболее интересная методология "моделирования в терминах системы" создана усилиями специалистов BAAN.



^

Анализ на базе семейства IDEF



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

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

Многие корпоративные информационные системы зарубежных производителей (SAP R/3, Baan, Ross iRenaissance и др.) имеют в своем составе специальные средства, основанные на собственных универсальных методиках. С помощью этих средств можно обследовать предприятие и построить модель их деятельности. Использование этих средств в нашей стране по вполне понятным причинам в на стоящее время затруднено. Однако существуют и стандартизированные методологии и инструментальные средства, прошедшие проверку временем, позволяющие решить эту задачу. К их числу и относятся стандарты семейства IDEF.

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

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




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




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

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

Теперь более подробно о стандартах. В настоящее время самыми распространенными являются следующие три стандарта (нотации) IDEF0, DFD и IDEF3. Каждая из этих нотаций позволяет рассмотреть различные стороны деятельности предприятия. Диаграммы IDEF0 предназначены для описания бизнес-процессов на предприятии. Они позволяют понять, какие объекты или информация служат сырьем для процессов, какие результаты следуют из проделанных работ, что является управляющими факторами и какие ресурсы для этого необходимы. Нотация IDEF0 помогает выявить формальные недостатки бизнес-процессов, что существенно облегчает анализ деятельности предприятия.

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

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

^

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



Основная идея объектно-ориентированного анализа и проектирования (object-oriented analysis and design) состоит в рассмотрении предметной области и логического решения задачи с точки зрения объектов (понятий и сущностей). В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области. В процессе объектно-ориентированного проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования. Эти программные объекты включают в себя атрибуты и методы. И, наконец, в процессе конструирования (construction) или объектно-ориентированного программирования (object-oriented programming) обеспечивается реализация разработанных компонентов и классов.


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

  • С начала производится так называемый анализ требований (requirements analysis) во время которого выделяются основные процессы, происходящие в моделируемой системе и их формулировка в виде прецедентов. Прецедент (precedent)- это текстовое описание процессов, происходящих в предметной области.

  • Шаг второй. Объектно-ориентированный анализ предметной области (object-oriented domain analysis). Задача этого шага в определении видов деятельности участников процесса и составлении концептуальной модели (conceptual model), которая отражает различные категории элементов предметной области. Причем не только виды деятельности участников, но и все относящиеся к делу понятия.

  • Шаг третий. Разбираемся, кто, чем занимается. Эта деятельность и называется объектно-ориентированным проектированием (object-oriented design), при котором основное внимание сосредоточено на распределении обязанностей. Распределение обязанностей (responsibility assignment) означает выделение задач и обязанностей различных программных объектов в приложении.


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




Скачать 0,92 Mb.
оставить комментарий
страница5/13
Дата30.09.2011
Размер0,92 Mb.
ТипЛекция, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы: 1   2   3   4   5   6   7   8   9   ...   13
отлично
  3
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Документы

наверх