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

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


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

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



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

Моделирование контекста системы



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

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

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


Моделирование контекста системы состоит из следующих шагов:

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

  • Организуйте похожих актеров с помощью отношений обобщения/специализации.

  • Введите стереотипы для каждого актера, если это облегчает понимание.

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


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

^

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



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

Требование (requirement) - это особенность проекта, свойство или поведение системы. Приступая к сбору требований, вы как бы описываете условия контракта, заключаемого между системой и сущностями вне ее, в котором декларируете, что система должна делать. При этом, как правило, вас заботит не то, как именно система будет выполнять поставленные перед ней задачи, а только то, что она будет делать. Хорошо спроектированная система должна полностью выполнять все требования, причем делать это предсказуемо и надежно. Ее создание начинается с соглашения о том, каково ее назначение, хотя в ходе разработки понимание требований будет постоянно изменяться. Аналогично при работе с готовой системой понимание того. Как она себя ведет, имеет принципиальное значение для ее правильного использования.


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

  • Установите контекст системы, идентифицировав окружающих ее актеров.

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

  • Назовите эти общие варианты поведения как прецеденты.

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

  • Смоделируйте эти прецеденты, актеров и отношения между ними на диаграмме прецедентов.

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


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

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

Группа развертывания сообщает о том, как программный комплекс разбита пакеты, в каком виде он поставляется, как устанавливается и запускается на площадке заказчика.
^

ЛЕКЦИЯ 7. Введение в унифицированный процесс моделирования




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



Унифицированный язык моделирования (UML - Unified Modeling Language) является стандартным инструментом для создания документированных каркасов ("чертежей") программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать процесс разработки программных систем. UML разработан таким образом, чтобы удовлетворять потребности при моделировании любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. Изучение UML мы начнем с его концептуальной модели, которая содержит три основные элемента языка: базовые конструкции, правила, определяющие, каким образом эти конструкции могут сочетаться между собой, и некоторые общие механизмы языка.

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


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

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

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

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

UML - это язык визуализации



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

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

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

^

UML - это язык специфицирования



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

^

UML - это язык конструирования



Хотя он и не является языком визуального программирования. Но модели, которые создаются с его помощью, могут быть непосредственно переведены на любой объектно-ориентированный язык программирования. Те понятия, которые удобнее представлять графически, так и подставляются в UML, те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования.

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

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

^

UML - это язык документирования



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

  • требования к системе;

  • архитектуру;

  • проект;

  • исходный код;

  • проектные планы и сметы;

  • тесты;

  • прототипы;

  • версии и другие.


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

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

Язык UML предназначен, прежде всего, для разработки программных систем. Его использование особенно эффективно в следующих областях:


  • информационные системы масштаба предприятия;

  • банковские и финансовые услуги;

  • телекоммуникации;

  • транспорт;

  • оборонная промышленность, авиация, космонавтика;

  • торговые системы;

  • медицинская электроника;

  • наука;

  • распределенные Web-системы.


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

Для понимания UML необходимо усвоить основные принципы, положенные в структуру этого языка. Этих принципов всего три, а сам язык как бы состоит из трех частей: основные конструкции языка, правила их взаимодействия и некоторые общие для всего языка механизмы. Освоив эти идеи, вы сумеете читать модели на UML и самостоятельно их разрабатывать, естественно, вначале не очень сложные. По мере приобретения навыков работы с языком вы научитесь использовать и более развитыми его возможностями.


Словарь UML включает три вида основных конструкций:

  • сущности - абстракции, являющиеся основными элементами модели;

  • отношения - связи между сущностями;

  • диаграммы, группирующие представляющие интерес множества сущностей и отношений.


Теперь обо всем более подробно.





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

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

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

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

наверх