Методические указания по выполнению лабораторной работы Подготовила: Романова Т. Н (стр. 1 из 6)

Московский Государственный Технический Университет им. Н. Э. Баумана

Кафедра “Программного обеспечения ЭВМ и информационные технологии”

Лабораторная работа №2

По курсу “Технология программирования”

Моделирование информационных систем с использованием CASE средств

Методические указания по выполнению лабораторной работы

Подготовила: Романова Т.Н.

доц. кафедры ИУ-7, к.ф.-м. н.

Москва 2011 г.

Содержание

Содержание…………………………………………………………………………………………2

Постановка задачи………………………………………………………………………………….3

Краткие теоретические сведения………………………………………………………………….4

Список литературы………………………………………………………………………………..30

Цель работы - знакомство с унифицированным языком моделирования (UML), знакомство с пакетом визуального моделирования Rational Rose в соответствии с методологией Rational

Unified Process и приобретение навыков разработки технического задания в соответствии

с требованиями ЕСПД и навыков моделирования конкретной информационной системы

в CASE системе Rational Rose 2000.

Постановка задачи

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

2. Разработать техническое задание (ТЗ) на информационную систему, которую будете моделировать в лабораторной работе №2 в соответствии со стандартами (Единой системой программной документации).

В CASE системе спроектировать выбранную ИС:

Поведение разрабатываемой системы, то есть функциональность, обеспечиваемую системой, (функциональную модель) описать с помощью диаграмм прецедентов (use case diagrams).
Основным средством для представления статической модели ИС является

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

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

собой. Промоделировать размещение компонентов.

Средствами CASE системы сгенерировать код ИС.
Представить отчет о выполнении лабораторной работы №2 по схеме.

· Титульный лист.

· Введение, описание предметной области, необходимость создания ИС.

· Техническое задание по ЕСПД.

· Распечатки всех построенных в CASE системе диаграмм.

· Описание атрибутов и спецификаций.

· Выводы о достоинствах и недостатках CASE системы для моделирования выбранного класса задач.

· Список использованной литературы.

Краткие теоретические сведения.

АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ.

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

Спецификации программного обеспечения при структурном подходе

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

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

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

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

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

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

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

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

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

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

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

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

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

● диаграмм потоков данных (DFD - Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

● диаграмм “сущность-связь” (ERD - Enity Relationhship Diagrams), описывающих базы данных разрабатываемой системы;

● диаграмм переходов состояний (STD - State Transition Diagrams), характеризующих поведение системы во времени;

● спецификаций процессов;

● словаря терминов.

Взаимосвязь элементов такой обобщенной модели показана на рис.2

Рис.2. Элементы полной спецификации методологий структурного анализа и проектирования программного обеспечения основанных на потоках данных

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

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

Обычно описание термина в словаре выполняют по следующей схеме:

● термин;

● категория (понятие предметной области элемент данных условное обозначение и т. д.);

● краткое описание.

В качестве примера приведем описание одного из терминов системы решения комбинаторно-оптимизационных задач: