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

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


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

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



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

Структурные сущности



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

^ Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой. Класс реализует один или несколько интерфейсов.


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


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


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


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


^ Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие. Активный класс практически полная копия обычного, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов.


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


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


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


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

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

^

Архитектурные виды



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

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

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

  • вид с точки зрения процессов (process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы.

  • вид с точки зрения реализации (implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой;

  • вид с точки зрения развертывания (deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющий физическую систему.


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

ЛЕКЦИЯ 3. Рациональный унифицированный процесс




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



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

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





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

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

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

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

наверх