![]() КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Основные сведения. Цель –научиться использовать uml-редактор staruml для анализа требований к по
АНАЛИЗ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ ЛАБОРАТОРНАЯ РАБОТА 2
Цель – научиться использовать UML-редактор StarUML для анализа требований к ПО ЗАДАНИЕ 1. Ознакомиться с рабочим потоком анализа прецедента (технологическим процессом анализа требований к ПО) в соответствии с методологией Unified Process 2. Изучить средства языка UML, для анализа требований 3. Используя пакет StarUML,: - создать диаграммы классов анализа - реализовать прецеденты: уточнить диаграмму вариантов использования и диаграммы взаимодействий: диаграмму последовательностей и диаграмму коммуникаций - отредактировать спецификации этих диаграмм 4. Подготовить и защитить отчёт по лабораторной работе Анализ в большой степени пересекается с определением требований. Эти две деятельности часто идут рука об руку. Обычно необходимо провести некоторый анализ требований, чтобы сделать их более понятными и выявить все упущения или искажения [1,4,14]. В рабочем потоке UP Анализ прецедента (технологическом процессе анализа) создаются два ключевых артефакта: - классы анализа – ключевые понятия в бизнес-сфере; - реализации прецедентов – иллюстрируют, как экземпляры классов анализа могут взаимодействовать для реализации поведения системы, описанного прецедентами. Входные данные Анализа прецедента: - бизнес-модель – в распоряжении разработчиков модели может быть (а может и не быть) бизнес-модель моделируемой системы. Если она уже есть, это превосходный источник требований. - модель требований - модель прецедентов - описание архитектуры – представление важных с архитектурной точки зрения аспектов системы. Может включать фрагменты UML-моделей, вставленные в пояснительный текст. Создается архитекторами на основании данных, полученных от аналитиков или проектировщиков. Классы анализа – это классы, которые представляют четкую абстракцию предметной области (problem domain) и должны проецироваться на реальные бизнес-понятия (и быть аккуратно поименованы соответственно этим понятиям). Напомним, что под классом понимается множество объектов, связанных общностью свойств, поведения связей и семантики. Любой объект является экземпляром (instance)класса[4]. Важно, чтобы все классы аналитической модели являлись классами анализа, а не классами, вытекающими из проектных соображений (области решения). Аналитическую модель системы среднего размера и сложности включает от 50 до 100 классов анализа. Диаграмма классов (анализа) является одной из важнейших диаграмм UML. Она используется для документирования программных систем, и основным ее компонентом является класс. Класс на диаграмме изображается в виде прямоугольника, разделенного горизонтальными линиями на три части. В первой части указывается название класса. Как правило, имя класса состоит из одного, максимум двух слов. Вторая часть содержит перечень атрибутов класса, которые характеризуют тот или иной объект этого класса в модели предметной области. Третья часть содержит перечень операций, отражающих его поведение в модели предметной области (рис.2.1) [2]. Атрибут класса – поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства. Рис. 2.1 Операция класса – это реализация услуги, которую можно запросить у любого объекта данного класса. Слева от имен атрибутов и операций указываются модификаторы видимост, символы и значения которых представлены в таблице (рис. 2.2) [1,2]. Рис. 2.2
Между элементами диаграммы классов существуют различные виды связей. Основные типы связей представлены на рис. 2.3 [1,2,4,]
Рис. 2.3 Реализация прецедентов – важнейшая часть процесса анализа, которая показывают, как взаимодействуют классы, чтобы реализовать функциональность системы [1,4]. У каждого прецедента только одна реализация, поэтому, создание диаграммы реализаций прецедентов не привнесет никакой дополнительной информации. Реализации прецедентов обычно не отображаются на диаграммах – это неявная часть базы модели, включающая элементы, представленные на рис.2.4;.
Рис. 2.4 Детальное описание диаграмм классов анализа можно найти в большинстве книг по UML, которые приведены в списке литературы. Кроме диаграмм классов можно создать или откорректировать ранее созданные диаграммы взаимодействий, демонстрирующие совместную работу и взаимодействие экземпляров этих классов анализа, направленные на реализацию части или всего поведения прецедента. Кроме изученных в лабораторной работе № 1 диаграмм последовательностей и коммуникационные диаграммы, полезными могут быть диаграммы обзора взаимодействий и временные диаграммы. Диаграммы обзора взаимодействий (interaction overview diagrams) показывают, как сложное взаимодействие реализуется рядом простых взаимодействий. Это особый случай диаграммы деятельности, в которой узлы ссылаются на другие взаимодействия. Они полезны для моделирования потока управления системы.[1] Временные диаграммы (timing diagrams) обращают внимание на фактическое время взаимодействия. Их основное назначение – помочь оценить временные затраты. [1] Временные диаграммы и диаграммы обзора взаимодействий, к сожалению, не поддерживаются пакетом StarUML, поэтому на лабораторных работах не изучаются. Объектно-ориентированное моделирование – итеративный процесс. Поэтому не надо удивляться, если при более глубоком моделировании будут выявлены новые требования или понадобится изменить существующие прецеденты. Все это – часть реализации прецедентов. Существующие документы должны соответствовать самой последней информации о системе. Необходимо обновлять модель прецедентов, модель требований и классы анализа, чтобы все они были согласованными
Дата добавления: 2015-04-30; Просмотров: 1244; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |