Введение в базы данных (1176852), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Полный контроль всего происходящего в проекте посредством создания специальных архивов.

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

Использование визуального моделирования

Применение не только механизмов Объектно-ориентированного программирования, но и ОО мышления и подхода

Этапы работ:

1. Бизнес моделирование

2. Требования

3. Анализ и проектирование

4. Кодирование

5. Тестирование

6. Развертывание

Стадии:

1. Inception

2. Elaboration

3. Construction

4. Transition

Конец стадии – контрольная точка, а, следовательно, и точка принятия решения.

После третей стадии обычно выходит бета версия.

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

Сам RUP поставляется в виде не обычного программного продукта, а в виде "on-line" документации, оформленной в виде web-страницы, что позволяет размещать его на внутренней сети предприятия с целью приобщения всех сотрудников к гигантскому кладезю полезной информации.

Итак, у нас есть:

1. UC модель, (список actor-ов)

2. Необходимо расставить приоритеты UC (high, mid, low)

Каждый UC имеет статус:

1. предложен

2. принят

3. спроектирован

4. закодирован

5. тестирован

6. интегрирован

Следовательно, можно сделать выводы, что у UC появляются атрибуты

Каждый шаг UC – это элементарная функция (и они тоже имеют состояние)

У Rational есть продукт, который облегчает все работу над процессами, и имя ему:

Requisite PRO.

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

Word

БД

требование

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

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

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

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

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

1. Договориться о GUI (окна, кнопочки, одним словом control элементы)

Эту структуру для конкретного сценария представляют заказчику.

1. Реализация UC.

1. Основные диаграммы UML. Формулирование требований на UC в виде Rational Case.

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

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

Class diagram (диаграммы классов)

Диаграмма классов - это набор статических, декларативных элементов модели, таких как классы, интерфейсы и их отношения. Диаграммы могут организовываться в модули (packages).

Диаграммы отображают классы системы и их взаимоотношения. Диаграммы классов – это основа объектно-ориентированного моделирования. Они используются для отображения того, что делает система (анализ) и как система будет построена (проектирование). Как правило, классы разрабатываются командой.

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

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

UML sequence diagram (диаграммы последовательности)

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

Традиционно диаграммы последовательностей отображают типы объектов, взаимодействующих в сценариях, сообщения которые они посылают друг другу и любые возвращаемые значения, ассоциированные с этими сообщениями (многие разработчики отображают возвращаемые значения, только если это не очевидно из контекста). Объекты (экземпляры) в UML отображаются подчеркнутыми, чтобы отличить их от классов. Для больших приложений, общим является у объектов дополнительно показывать компоненты и сценарии в верхней части диаграммы. Это имеет смысл, потому что компоненты, действительно только повторно используемые объекты и сценарии представлены как объекты, чья роль инкапсулировать процесс и поток управления, определенный в сценарии. Основная идея - это то, что диаграмма последовательности показывает "прохождение" логики выполнения в сценарии, позволяя вам документировать и реально контролировать проект вашего приложения. Прямоугольники на вертикальных линиях показывают "время жизни" объекта. Линии со стрелками и надписями названий методов означают вызов метода у объекта.

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

Collaboration diagram (диаграммы взаимодействия)

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

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

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

Component diagram (диаграммы компонентов)

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

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

Deployment diagram (диаграммы топологии, развертывания)

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

Statechart diagram and Activity diagram (диаграммы состояния и диаграммы активности)

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

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

Activity diagram:

Характеристики

Список файлов лекций