Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008




НазваниеПроектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008
страница1/3
Дата07.02.2013
Размер0.49 Mb.
ТипМетодические указания
  1   2   3



ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ


ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ


«САМАРСКИЙ ГОСУДАРСТВЕННЫЙ

АРХИТЕКТУРНО-СТРОИТЕЛЬНЫЙ УНИВЕРСИТЕТ»


Кафедра прикладной математики и вычислительной техники


Проектирование информационных


систем по методологии UML


Методические указания к учебно-лабораторному практикуму


Утверждены редакционно-издательским

советом университета 21 января 2008 г.


Самара 2008



Составители В.П. Дерябкин, В.В. Козлов


УДК 001+62+37+681.3.015+621.001.2+517.5


Проектирование информационных систем по методологии UML: Мето­дические указания к учебно-лабораторному практикуму /

Сост. В.П. Дерябкин, В.В. Козлов; Самарск. гос. арх.-строит. ун-т. - Самара, 2008. - 42 с.


Изложены методика и порядок выполнения учебно-лабораторного практикума по курсу «Проектирование информационных систем».

Предназначены для студентов пятого курса (9 семестр) специальности 230201 «Информационные системы и технологии».


© Самарский государственный архитектурно-

строительный университет, 2008


2

Общая часть

Методические указания предназначены для проведения лабораторного практикума по объектно-ориентированному проектированию программного и информационного обеспечения информационных систем (ИС) с применением унифицированного языка моделирования UML. Семестровый лабораторный практикум рассчитан на 34 академических часа и включает 8 четырёхчасовых методически связанных лабораторных работ (последнее занятие рассчитано на приём отчётов и подведение итогов). На конкретных примерах осваиваются основные этапы разработки проекта программного и информационного обеспечения системы с использованием методологии UML [1-3]. Параллельно с работой в аудитории над проектом студентами в порядке самостоятельной внеаудиторной работы в объёме 34 часов ведётся выполнение домашних заданий и реализация прототипа системы в согласованной с преподавателем программной и информационной среде. При этом на каждом занятии, кроме первого, осуществляется проверка домашних заданий предыдущего занятия и выполнение текущих аудиторных заданий. Такая методика позволяет более глубоко вникнуть в особенности применения методологии UML и избежать грубых ошибок в проекте и его реализации. Лабораторный практикум также может быть выполнен в демонстрационном ознакомительном режиме в сокращённом объёме на описанном контрольном примере без домашних заданий и реализации проекта, что иногда требуется по программам различных видов обучения. Данный материал входит в состав преддипломного курса по специальности 230201 «Информационные системы и технологии». Он также будет полезен студентам других специальностей, связанных с анализом, разработкой и использованием автоматизированных систем и программных комплексов и обучающихся как по очной, так и по заочной формам обучения.

Проектирование программного и информационного обеспечения информационных систем (ИС) и программных комплексов (ПК) является сложной задачей, в процессе решения которой приходится рассматривать широкий круг вопросов, связанных с моделированием предметной области, анализом информационных потоков, разработкой схем баз данных и алгоритмов сбора и обработки информации, выбором комплекса технических и системных программных средств, документированием проекта. В настоящее время проектирование ведется коллективами разработчиков с использованием специальных инструментальных программных систем – CASE-средств (Computer-Aided Software/System Engineering) [2]. В качестве теоретического базиса проектирования большинство CASE-технологий используют методы структурного системного анализа. Использование концепции объектно-ориентированного программирования [ 1 ] и усложнение ИС потребовало в настоящее время дальнейшего развития методов и инструментальных средств структурного анализа и синтеза. Последним достижением в этой об-

3

ласти стал объектно-ориентированный метод анализа и проектирования сложных систем с использованием унифицированного языка моделирования UML и CASE-систем Rational Rose, XDE и аналогичных [ 1-3 ].

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


Лабораторная работа № 1. Построение диаграммы вариантов использования


Цель работы: выполнение начального этапа разработки системы – анализ требований, предъявляемых к системе; построение части функциональной модели системы - диаграммы вариантов использования.


Основные теоретические сведения


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

    Класс – некоторая абстракция совокупности объектов, имеющих общий набор свойств и обладающих одинаковым поведением. Классы характеризуются атрибутами (свойствами) и операциями, определяющими поведение класса. Реализация операции класса называется в UML методом класса.

    Объект – экземпляр соответствующего класса с собственным именем и конкретными значениями атрибутов. Объект обладает всеми операциями класса.

    Классы могут быть организованы в иерархическую структуру, напоминающую по своему виду схему классификации. Основным принципами объектно-ориентированного подхода являются наследование, инкапсуляция и полиморфизм [1 ].

    Наследование - принцип, в соответствии с которым родительский класс (предок) передает все свои наборы свойств и поведение дочерним классам (потомкам).

    Инкапсуляция - сокрытие деталей внутреннего устройства классов от внешних для него объектов или пользователей.

    Полиморфизм (много форм) - действия, выполняемые одноимёнными методами, могут отличаться в зависимости от того, к какому из классов относится метод.

Процесс создания системы носит итеративный и инкрементный харак –

4


тер. Это же подчеркивают и авторы UML, определяя понятие унифицирован-

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

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

  • модель вариантов использования;

  • модель анализа ;

  • модель проектирования;

  • модель реализации;

  • модель развертывания;

  • модель тестирования.

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

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

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

    Диаграммой самого верхнего уровня является диаграмма вариантов использования системы в целом. Именно она является исходным концептуальным представлением системы и строится с целью:

  • определить общие границы и контекст моделируемой предметной области;

  • сформировать общие требования к функциональному поведению и

    интерфейсу системы;

    5

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

    Точка зрения модели: внешний пользователь системы. В диаграмму вариантов использования входят актанты (actors), варианты использования (use case) и ассоциации (association).

    Актант (актер, внешняя сущность, actor) - абстрактное описание класса источников/приемников сообщений, которые напрямую взаимодействуют с системой, подсистемой или классом. Это-описание роли, которую играет пользователь (человек или другая система, подсистема, класс) во время взаимодействия с системой. На самом верхнем уровне, например, актантами могут являться оператор, системный администратор, администратор базы данных, обычный пользователь, какой-либо класс устройств.

    Каждая роль требует для себя вполне определенного сервиса (обслуживания).

    Один человек или физический объект в зависимости от режима взаимодействия может представлять собой несколько актантов (разные роли). Например, один и тот же человек может быть оператором и администратором базы данных, продавцом и покупателем и т.п. Актант обычно изображается на диаграммах как “человек” с надписью (символ человека):




    Заказчик

    Актант находится вне системы и его внутренняя структура не определяется. Он является источником/приемником сообщений.

    Вариант использования (прецедент, use case) – абстрактное описание класса сервиса (сервисных функций), предоставляемого актанту в ответ на его запросы. Сервис могут предоставлять система в целом, подсистема или класс. Таким образом, вариант использования означает моделирование некоторой части функциональности или поведения системы. Вариант использования имеет имя и означает некоторую последовательность действий, видимых внешнему источнику/приемнику (актанту). Подробно этот процесс описывается сценарием, построение которого рассматривается в следующей лабораторной работе.

    Связь между актантом и вариантом использования показывается ассоциацией.

    На диаграмме вариант использования изображается обычно эллипсом, внутри ставится имя.

    Ассоциация показывается линией:





    Менеджер

    6

    Между актантами и вариантами использования ассоциация – единственный вид связи. Можно ее пометить, а также указать кратность связи. Имя ассоциации, если оно есть, должно быть уникальным.

    М


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

    В отношении расширения вариант использования – клиент вносит дополнительную последовательность действий, начиная с некоторой точки основной последовательности, при этом таких “вставок” может быть несколько. Все эти точки называются точками расширения.


    <>




    Направление стрелки имеет смысл: вариант “Запросить каталог” знает, в какой точке расширения варианта “Принять заказ” он начинает выполняться (таких точек может быть несколько). Для правильного определения направления стрелки следует задать вопрос по данному варианту: «Расширяет что?». Каждая точка расширения имеет уникальное имя в рамках варианта “Принять заказ”. Имена точек расширения можно указать в специальном разделе в обозначении варианта использования.

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


    Один и тот же вариант использования может использоваться как расширение для нескольких других вариантов.

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

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

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

    Для правильного определения направления стрелки следует задать вопрос по основным вариантам: «Включают что?». Каждая точка включения имеет уникальное имя в рамках варианта использования. Имена точек включения можно указать в специальном разделе в обозначении варианта использования

    7

    Пример:





    «include» «include»





    .

    Третье отношение между вариантами использования – обобщение (use case generalization) в обычном смысле. Прямой предок может иметь одного или нескольких прямых потомков:




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

    Порядок выполнения работы

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



Описание предметной области

Клиент, характеризуемый ФИО, почтовым адресом и номером контактного телефона, даёт заказ на приобретение одного или нескольких товаров с конкретной комплектацией, указываемой в строках заказа. При приёме заказа менеджером отдела заказов выписывается счёт, в котором указывается уникальный номер, дата и время счёта, максимальные дата/время оплаты и срок выполнения заказа, сумма счёта и построчный перечень товаров по справочнику товаров (порядковый номер строки, номенклатурный номер, наименование, единица измерения, количество, цена за единицу, стоимость ). Номер счёта соответствует номеру заказа, а дата-время счёта –дате-времени приёма заказа. Срок выполнения заказа и его полная стоимость зависят от

8

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

Сведения об оплате или её возврате вводит бухгалтер.

Информационные запросы производят:

  1. Менеджеры отдела заказов: по ФИО клиента вывести на экран сведения о его заказах за период не более 5 лет с указанием характеристик заказа в целом, фактов оплаты и состояния заказа; подсчитать общую стоимость выполненных и заключённых, но не аннулированных заказов раздельно и суммарно.

  2. Зав отделом заказов: вывести на экран в виде графика динамику изменения суммарной стоимости выполненных заказов по месяцам за определённый период длительностью не более трёх лет.

  3. Менеджеры отдела заказов: сформировать и вывести на экран и печать заказ и почтовое уведомление об аннулировании заказа для конкретного клиента.


Создайте диаграмму вариантов использования для проектируемой системы. Готовая диаграмма вариантов использования должна выглядеть как на рисунке 1. Нарисуйте линии ассоциации между актантами и соответствующими вариантами использования.


Добавить расширения

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

Добавьте вариант использования «Вести справочник товаров», расши-

9

ряющий вариант использования «Вести справочники».

Добавить включения


Добавьте варианты использования «Сформировать бланк заказа» и «Сформировать почтовое уведомление», включаемые в варианты использования «Ввести новый заказ» и «Аннулировать заказ» соответственно. Связь включения означает, что вариант использования «Сформировать бланк заказа» обязательно выполняется при выполнении варианта использования «Ввести новый заказ».

Указать абстрактные варианты использования


Сделайте вариант использования «Сформировать бланк заказа» абстрактным. Это значит, что данный вариант использования самостоятельных экземпляров не имеет и, соответственно, является фрагментом экземпляра базового варианта использования «Ввести новый заказ».

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

Укажите как абстрактные варианты использования «Сформировать почтовое уведомление» и «Формировать отчёты».



Рисунок 1 – Диаграмма вариантов использования Main

10


.

Лабораторная работа № 2. Создание сценариев модели

вариантов использования


Цель работы: выполнение начального этапа разработки системы – анализ требований, предъявляемых к системе; построение части функциональной модели системы - написание сценариев взаимодействия пользователей с системой.


Основные теоретические сведения


Сценарий (scenario) – [1] - текстовое описание последовательности действий, необходимых для выполнения экземпляра варианта использования. Сценарий пишется по определённому шаблону. Образцы описания сценариев приведены ниже. При создании сценариев тщательно прорабатывается интерфейс системы и учитываются отношения между вариантами использования, изложенные в предыдущей лабораторной работе. Для абстрактных вариантов использования, являющихся обобщениями конкретных вариантов, сценарии обычно не пишут.


  Порядок выполнения работы

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

Создать файлы сценариев для вариантов использования


С помощью текстового редактора для варианта использования «Войти в систему» создайте и сохраните в той же директории, где размешается модель, текстовый файл сценария Vhod, содержащий следующий текст:

Вариант использования: Войти в систему.

Краткое описание. Даёт возможность любому пользователю войти в систему по своему имени и паролю с настройкой интерфейса системы на соответствующие права доступа.

Актант. Пользователь.

Предусловия. Компьютер пользователя включён, на экране – главное окно операционной системы с набором пиктограмм на рабочем столе.

Основной поток событий

  1. Пользователь двойным щелчком левой кнопки мыши по пиктограмме «Учёт заказов» запускает приложение.

  2. На экране появляется форма ввода имени пользователя и пароля с по-

11

лями ввода «Имя», «Пароль» и с кнопками «ОК» и «Выход».

  1. Пользователь вводит имя и пароль и щёлкает кнопку OK.

А1: Щёлкнута кнопка «Выход».

  1. Система проверяет имя и пароль.

  2. Система закрывает форму ввода имени и пароля и выводит на экран главную форму приложения с пунктами меню «Заказы», «Справочники», «Оплата», «Склад», «Отчёты», «Справка», «Выход». Состав пунктов меню настраивается в соответствии с правами пользователя. Вариант использования завершается успешно.

А2: Имя и/или пароль неверны.

Альтернативы

А1: Щёлкнута кнопка «Выход».

А1.1. Система закрывает форму ввода имени и пароля и выводит на экран главное окно операционной системы. Вариант использования завершается .

А2: Имя и/или пароль неверны.

А2.1. Система выводит сообщение о неверном вводе имени и/или пароля и просит повторить вход или выйти из приложения. В последнем случае вариант использования завершается .

Постусловия. При успешном завершении на экране – главная форма приложения с меню, настроенном на права пользователя.

Неясные вопросы. Уточнить права пользователей и настройки.


Аналогично создайте файлы сценариев для остальных конкретных вариантов использования и сохраните их. Сценарии абстрактных вариантов включите непосредственно в конкретные.


  • Ввести новый заказ: Vvodzak.doc

Вариант использования: Ввести новый заказ.

Краткое описание. Позволяет менеджеру ввести информацию о новом заказе, произвести его комплектацию, установить стоимость и сроки выполнения заказа, а также подготовить и вывести на печать счёт на оплату. Включает вариант использования "Сформировать счёт на оплату". Расширяет вариант использования "Вести информацию о заказах".

12

Актант. Менеджер.

Предусловия. Пункты 1,2 варианта использования " Вести информацию о заказах " выполнены, в пункте 3 выбрана альтернатива А2.

Основной поток событий

              1. Система выводит на экран форму ввода нового заказа с полями: «Номер заказа», «Дата-время заказа», «Название», «ФИО клиента», «Адрес», «Телефон контакта», «Сумма», «Дата-время выполнения», «Дата-время оплаты», «Статус заказа», «Менеджер». На форме располагается таблица просмотра и редактирования позиций заказа с полями: «Номер позиции», «Наименование товара», «Единица измерения», «Цена за единицу», «Количество», «Стоимость». На форме также имеются кнопки «Добавить позицию», «Удалить позицию», «Оформить счёт», «ОК», «Отмена». Поле «Номер заказа» заполняется системой автоматически увеличением предыдущего значения на 1, «Дата-время заказа» – по таймеру компьютера, «Дата-время оплаты» и «Дата-время выполнения» – автоматически увеличением даты-времени заказа на определённое число, например, 72 часа ( 3 суток). Поле «Статус заказа» по умолчанию устанавливается в «Не оплачен, не выполнен», в поле «Менеджер» заносится ФИО менеджера по данным входа в систему.

              2. Менеджер щёлкает левой кнопкой поле «Название» и вводит название заказа. Аналогично вводятся данные по ФИО клиента, его адресу и телефону контакта.

              3. Менеджер щёлкает кнопку «Добавить позицию».

              4. Система выводит на экран форму резерва с упорядоченным по алфавиту перечнем товаров с указанием номенклатурного номера, наименования товара, единицы измерения, цены за единицу, имеющегося количества, поставщика. На форме имеется кнопка «Закрыть».

              5. Менеджер выбирает щелчком из перечня товаров необходимые для заказа позиции и щёлкает кнопку «Закрыть».

А1: В перечне нет товара, необходимого для комплектации заказа.

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

              2. Менеджер щёлкает и вводит в поле «Количество» первой позиции заказа требуемое количество товара.

13

А2: Щёлкнута кнопка «Удалить позицию».

А3: Щёлкнута кнопка «Отмена».

              1. Система автоматически уменьшает количество резерва по данному товару, одновременно добавляя указанное количество и другие данные по товару, а также номер заказа в таблицу товаров для выдачи по заказам и выводит в поле «Стоимость» рассчитанное значение стоимости позиции.

А4: Резерва товара недостаточно.

9, Повторяются пункты 7,8 для всех остальных позиций товара.

10. Менеджер щёлкает кнопку «ОК».

А3: Щёлкнута кнопка «Отмена».

А5: Щёлкнута кнопка «Оформить счёт».

  1. Система закрывает форму ввода заказов, и выводит на экран форму работы с заказами. Вариант использования завершается успешно.

Альтернативы

А1: В перечне нет товара, необходимого для комплектации заказа.

А1.1. Менеджер отказывается от ввода заказа и щёлкает кнопки «Закрыть» и далее «Отмена».

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

А2: Щёлкнута кнопка «Удалить позицию».

А2.1. Система удаляет из таблицы позиций заказа выделенную позицию, оставляя другие позиции без изменения, и обновляет форму ввода заказа.

А2.2. Пункт 7 повторяется.

А3: Щёлкнута кнопка «Отмена».

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

А4: Резерва товара недостаточно.


14

А4.1. Система выводит на экран форму с информацией о наличии то-

вара и возможности его поставки с полями: «Номенклатурный номер», «Наименование товара», «Поставщик», «Единица измерения», «Цена за единицу», «Срок поставки», «Максимальный объём поставки», «Требуется». На форме кнопки «Принять» и «Отмена». Кнопка «Принять» активизирована, если требуемое количество меньше или равно максимальному объёму поставки.

А4.2. Менеджер выбирает товар и щёлкает кнопку «Принять».

А4.2А: Щёлкнута кнопка «Отмена».

А4.2А1. Система отменяет действия пользователя по вводу нового заказа и выводит на экран главную форму приложения с меню, настроенным на права пользователя. Вариант использования завершается.

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

А4.4. Выполняется пункт 7 основной последовательности.

А5: Щёлкнута кнопка «Оформить счёт».

А5.1. Система выводит на экран форму предварительного просмотра счёта на оплату заказа с заголовком «Счёт на оплату №», «от» . На форме расположены поля: «Клиент», «Оплатить до», «Готовность», «Сумма без НДС», «НДС», «Всего», «Менеджер», а также таблица позиций заказа со столбцами: «№», «Наименование товара», «Кол-во», «Ед. изм.», «Цена», «Сумма». На форме имеются кнопки: «Печать» и «Закрыть». Система автоматически заполняет все поля и таблицу позиций по данным заказа, принимая налог на добавленную стоимость (НДС) в размере 20% от суммы заказа. В поле «Готовность» заносится дата-время выполнения заказа, номер счёта совпадает с номером заказа.

А5.2. Менеджер щёлкает кнопку «Печать».

А5.2А1: Щёлкнута кнопка «Закрыть».

А5.2А1.1. Форма предварительного просмотра счёта закрывает-

15

ся. На экране – форма ввода нового заказа.

А5.2А1.2. Повторяется пункт 10 основной последовательности.

А5.3. Система печатает бланк счёта на оплату заказа.

А5.4. Повторяется пункт 10 основной последовательности.

Постусловия. При успешном завершении на экране – форма работы с заказами.

Неясные вопросы. Уточнить работу с товарами, отсутствующими на складе.


Лабораторная работа № 3. Построение модели анализа.

Диаграмма классов


Цель работы: выполнение очередного этапа разработки системы – анализ способов реализации функциональных требований, предъявляемых к системе; построение части модели анализа - диаграммы классов для системы в целом.
  1   2   3

Похожие:

Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008 iconДипломная работа студентов уголовно-правовой специализациии методические указания Самара «Самарский университет»
Стп самгу 001-02. (Самара, 2002), Государственным стандартом гост 80-2000, утверждены на заседаниях кафедр уголовного процесса и...
Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008 iconМетодические указания к лабораторному практикуму по дисциплине «Основы автоматики и теория устройства технических систем»
Методические указания к лабораторному практикуму по дисциплине «Основы автоматики и теория устройства технических систем» для курсантов...
Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008 iconМетодические указания к лабораторному практикуму по дисциплине «Основы автоматики и теория устройства технических систем»
Методические указания к лабораторному практикуму по дисциплине «Основы автоматики и теория устройства технических систем» для курсантов...
Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008 iconКокин М. В., Оленина О. А. Составление сводного сметного расчета стоимости строительства: Методические указания
Рекомендовано редакционно-издательским советом университета в качестве методических указаний
Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008 iconРедакционно-издательским советом Томского политехнического университета Издательство Томского политехнического университета 2008 1
Государственное образовательное учреждение высшего профессионального образования
Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008 iconПрокурор в уголовном процессе самара Издательство: Самарский университет 2010 удк 343. 1
Утверждено в качестве учебного пособия редакционно-издательским советом университета
Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008 iconУтверждено редакционно-издательским советом университета
Информатика: Рабочая программа. Задание и методические указания к выполнению контрольной работы. Задание и методические указания...
Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008 iconУтверждено редакционно-издательским советом университета в качестве методических указаний к курсовому проектированию для студентов Самара 1998
Самарский Государственный аэрокосмический Университет имени академика С. П. Королева
Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008 iconИсследование электрического сопротивления тела человека методические указания к лабораторной работе №12 Москва 2006 Московский государственный университет путей сообщения (миит) Кафедра «Безопасность жизнедеятельности»
Рекомендовано редакционно-издательским советом университета в качестве методических указаний
Проектирование информационных систем по методологии uml методические указания к учебно-лабораторному практикуму Утверждены редакционно-издательским советом университета 21 января 2008 г. Самара 2008 iconМетодические указания к выполнению курсовой работы по дисциплине: Основы токсикологии для студентов дневного и заочного обучения специальности 280201 «Охрана окружающей среды и рациональное использование природных ресурсов»
Одобрено редакционно-издательским советом Саратовского государственного технического университета
Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница