Реферат: Министерство энергетики и промышленности республики таджикистан технологический университет таджикистана худжандский филиал «Утверждаю» Зав кафедрой

МИНИСТЕРСТВО ЭНЕРГЕТИКИ И ПРОМЫШЛЕННОСТИ РЕСПУБЛИКИ

ТАДЖИКИСТАН


ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ ТАДЖИКИСТАНА

ХУДЖАНДСКИЙ ФИЛИАЛ


«Утверждаю»

Зав. кафедрой__________

_______________________


_______________________

«____»____________2009 г.


КУРСОВАЯ РАБОТА


по дисц.Основы UML


Исполнитель Музаффаров /Алишер/

Курс 4 Группа 071900 РА


Руководитель Худойбердиев /Хуршед/


Результаты защиты


№ попытки

Оценка

Дата

Подпись

Попытка 1










Попытка 2










Попытка 3












Худжанд-2009

СОДЕРЖАНИЕ


ВВЕДЕНИЕ………………………………………………………………………

ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ………………………………………

ВОЗМОЖНОСТИ АВТОМАТИЗАЦИИ ДЕЛОПРОИЗВОДСТВО С ПРОГРАММ MS OFFICE………………………………………………………...

ОПРЕДЕЛЕНИЕ ПРОЦЕССОВ………………………………………………….

ОПИСАНИЕ ПРЕЦЕДЕНТОВ, ДИАГРАММА ПРЕЦЕДЕНТОВ…………….

ТИПИЧНЫЙ ХОД СОБЫТИЙ…………………………………………………..

КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ………………………………………………...

ФУНКЦИИ СИСТЕМЫ…………………………………………………………..

ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ, ВЗАИМОДЕЙСТВИЕ АКТЕРОВ С СИСТЕМОЙ………………………………………………………..

ТАБЛИЦЫ СИСТЕМНЫХ ОПЕРАЦИЙ………………………………………

РЕАЛЬНЫЕ ПРЕЦЕДЕНТЫ С ИНТЕРФЕЙСНЫМИ ФОРМАМИ………….

ДИАГРАММА КООПЕРАЦИИ, РАСПРЕДЕЛЕНИЕ ОБЯЗАННОСТЕЙ МЕЖДУ КЛАССАМИ……………………………………………………………

ДИАГРАММА СОСТОЯНИЙ…………………………………………………..

ДИАГРАММА КЛАССОВ………………………………………………………

ДИАГРАММА РАЗВЕРТЫВАНИЯ…………………………………………….

РАСЧЕТ СТОИМОСТИ ИС……………………………………………………..

ЗАКЛЮЧЕНИЕ…………………………………………………………………..


^ СПИСОК ИСПОЛЬЗУЮМЫЙ ЛИТЕРАТУРЫ.


ВВЕДЕНИЕ


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

Построение АИС является начальным этапом процесса разработки систем управления базам данных (СУБД). СУБД, в свою очередь, являются совокупностью, предназначенной для обработки на ЭВМ поименованных данных, которая служит для запросов многих пользователей в рамках организации (предметной области).

Целью данного курсового проекта является создание автоматизированной информационной системы заданной предметной области – Компьютерного магазина


^ ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ


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

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




Рис 1. Логотип компьютерного магазина


Компьютерный магазин AMSH продаёт, ремонтирует, собирает любую конфигурацию по доступным ценам. Компьютерный центр "AMSH" - это магазин в котором продаются:


Компьютеры

Ноутбуки

Комплектующие

Акустические системы

Оргтехника (принтеры, сканеры, копиры, уничтожители бумаг и т.д.)

Телефоны, факсы

Цифровые фотоаппараты и веб-камеры

Расходные материалы и запчасти

Лицензионное программное обеспечение (Бухгалтерия, ОС Windows и многое другое)

Игры и мультимедиа


Компьютерный центр "AMSH" - это магазин в котором оказывается целый ряд услуг:


Модернизация компьютеров

Заправка картриджей всех видов

Ремонт оргтехники

Ремонт компьютеров и комплектующих

Установка и настройка программного обеспечения

Проведение и настройка компьютерных сетей

И многое другое ...

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


Ваши жалобы, предложения и вопросы вы можете оставить здесь. Либо вы можете прислать их по адресу: alisher64318@mail.ru или на сайт www.alisherjon-muzaffarov.narod.ru


^ ЭТАП АНАЛИЗА


Этап анализа состоит в исследовании системных требований и проблемы. Содержание понятия анализа более точно отражают термины анализ требований (requirment analysis) (т.е. исследование требований к системе) и объектно-ориентированный анализ (object-oriented analysis) (исследование объектов предметной области). В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области.

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

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


^ ВОЗМОЖНОСТИ АВТОМАТИЗАЦИИ ДЕЛОПРОИЗВОДСТВО С ПРОГРАММ MS OFFICE


MS_WORD: Квитанция, Прайс-лист, Визитные карточки, Перечень Услуг, Список программных обеспечений

MS_EXCEL: Бухгалтерия – Зарплата работников, Расчет налогов, Чистый доход предприятия, Расход,

MS_Power Point: Внутренняя реклама, Ознакомление компанией, Достижение предприятия

MS_ACCESS : База данных товаров, клиентов, рабочих, заказов,

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

MS_VISIO : Планы магазина на будущее – расширение товаров и услуг, создание филиалов в других городах и районах РТ



^ ОПРЕДЕЛЕНИЕ ПРОЦЕССОВ


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

Для моделирования процессов удобно использовать диаграммы IDEF0.

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


Определите назначение модели – набор вопросов, на которые должна отвечать модель.

Обозначьте границы моделирования (ширину охвата предметной области и глубину детализации)

Укажите предполагаемую целевую аудиторию, для нужд которой создается модель. От этого может зависеть уровень детализации модели.

Выделите функциональный блоки модели.

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


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


Ниже на рисунке 2 приведен пример описания процесса Покупка товара.




Прайс-лист





Клиент Покупка Сдача, чек и товар

Товара





Деньги


Рис. 2. Описание процесса Покупка товара в терминах IDEF0_


^ ОПИСАНИЕ ПРЕЦЕДЕНТОВ, ДИАГРАММА ПРЕЦЕДЕНТОВ


Описание прецедентов


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


Для выделения прецедентов используется следующая процедура.


^ Определите рамки системы: является ли она программным приложением, аппаратно-программным комплексом, включает ли в себя своих пользователей или всю организацию?

Идентифицируйте основных исполнителей, потребности (цели) которых удовлетворяются с помощью системы.

Для каждого исполнителя определите его задачи.

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


Пример описания приведен ниже для прецедента Запрос о состояния магазина.

Таблица 1

^ Описание прецедента Запрос о состояния магазина


Название прецедента

Запрос о состояния магазина

Исполнитель

Директор

Цель

Запросит о состояния магазина, сколько доходов и расходов, состоянии слада, заказа, витрины, услуги и т.д

^ Основной успешный
сценарий

Директор запрашивает работнику о состояния магазина и работник запросит на компьютера 5 - запроса на База данных компьютерного магазина и приходит 5 отчетов это отчет Заказы, Склад, Поставщик, Витрина и Услуги и работник передаёт эти отчеты в одном отчете на Директор.

Тип

Идеальный

Ссылки

Функции: Запрос и Отчет



Диаграмма прецедентов описывает типичное взаимодействие между пользователем и системой. На данной диаграмме прецедентов человеческие фигурки обозначают действующих лиц, овалы – прецеденты, а линии и стрелки – различные связи между действующими лицами и прецедентами. Пример диаграммы прецедентов приведен на рисунке 3. Исполнитель (actor) – это сущность, обладающая поведением. Выделяют три типа исполнителей. Основной исполнитель (primary actor) – его задачи выполняются с использованием системы. Примером основного исполнителя является кассир. Вспомогательный исполнитель (supporting actor) – обслуживает систему (например, предоставляет информацию). Закулисный исполнитель (offstage actor) – заинтересован в реализации прецедента, но не является основным или вспомогательным исполнителем.


Основной исполнитель (primary actor) – Директор

Вспомогательный исполнитель (supporting actor) – Работники

Закулисный исполнитель (offstage actor) - Поставщик




Рис. 3. Диаграмма прецедентов ИС Компьютерный магазин AMSH Ent…


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


Эти сценарии дублируются в других прецедентах.


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

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

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

^ ТИПИЧНЫЙ ХОД СОБЫТИЙ


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

Таблица 2

Описание типичного хода событий прецедента Запрос о состояния магазина


^ Действия исполнителя

Отклик системы

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




Работник заходит в кабинет директора вместе ноутбуком и директор запрашивает о состояния магазина и работник открывает ноутбук и на систему магазина отправляет запрос.







Система отправляет 5 запросов на базу данных.




Система принимает 5 отчетов и обрабаты-вает потом в одном отчете оказывает на браузер

Работник распечатывает через бес-проводной принтер, принтер находятся в правой стороны директора.




Директор из лоток принтер берёт бума-гу и анализирует.






^ КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ.


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


Выделите концептуальные классы.

Отобразите их в модели предметной области в виде классов на диаграмме UML.

Добавьте необходимые ассоциации и атрибуты.


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





Рис. 4. Фрагмент модели предметной области


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


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


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


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


Три стратегии идентификации концептуальных классов.


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

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

На основе выделения существительных идентифицировать связи (ассоциации) между концептуальными классами.



Таблица 5

Список категорий концептуальных классов


Категория концептуальных классов

Примеры

Транзакции

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

Sale (Продажа). Payment (Платеж). Re-
servation (Резервирование)

Элементы транзакций
Рекомендации: транзакции зачастую
состоят из элементов

SalesLineltem (Элемент продажи)

Товары или службы, связанные с
транзакциями или их элементами
Рекомендации: транзакции выполня-
ются над некоторыми элементами
(товарами или службами)

Item (Элемент). Flight (Рейс), Seat (Ме-
сто)

Места записи транзакций
Рекомендации: очень важная катего-
рия

Register (Реестр). FlightManifest (Распи-
сание полетов)

Роли людей или организации, связан-
ные с транзакциями. Исполнители
прецедентов

Рекомендации: необходимо знать, кто
участвует в транзакции

Cashier (Кассир), Customer (Покупа-
тель), Store (Магазин). MonopolyPlayer
(Игрок), Pilot (Пилот). Passenger (Пас-
сажир)

Места транзакций

Store (Магазин). Airport (Аэропорт).
Plane (Самолет), Seat (Место)

Важные события, для которых необ-
ходимо хранить время и место

Sale (Продажа). Payment (Платеж).
MonopolyGame (Монополия), Flight
(Полет)

Физические объекты
Рекомендации: такие объекты обычно
соответствуют программным систе-
мам. предназначенным для управле-
ния или моделирования

Register (Реестр). Airplane (Самолет),
Item (Товар), Board (Доска), Die (Иг-
ральная кость)

Описание объектов

ProductDescription (Каталог товаров)
FlightDescription (Каталог рейсов)


Продолжение табл. 5

Категория концептуальных классов

Примеры

Каталоги

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

ProductDescription (Каталог товаров)
FlightDescription (Каталог рейсов)

Контейнеры других объектов (физи-
ческих или информационных)

Store (Магазин). Bin (Бункер). Airplane
(Самолет). Board (Доска)

Содержимое контейнеров

Item (Элемент). Square (Клетка на дос-
ке). Passenger (Пассажир)

Другие системы, внешние по отноше-
нию к данной системе

CreditAuthorizationSystem (Система ав-
торизации кредитных платежей). Air-
Traffic Control (Система управления
движением)

Записи финансовой, трудовой, юри-
дической и другой деятельности

Receipt (Чек). Ledger (Гроссбух), Main-
tenance!, og (Журнал обслуживания)

Финансовые инструменты

LineOfCredit (Кредитная линия). Cash
(Наличные). Check (Чек)

Руководства, документы, статьи, кни-
ги. на которые ссылаются в процессе
работы

DailyPriceChangeList (Бюллетень еже-
дневного изменения цен). RepairManual
(Руководство по восстановлению)



^ Ассоциация (association) – это отношение между классами, отражающая некоторые значимые и полезные связи между ними. Ассоциация обозначается проведенной между классами линией, с которой связано определенное имя, начинающееся с большой буквы. На рисунке 5 приведен пример ассоциации.





Рис. 5. Система обозначений ассоциаций в языке UML


Дополнительная стрелка рядом с именем ассоциации указывает, в каком направлении нужно читать ее имя. Если такая стрелка отсутствует, то имена ассоциаций следует читать с использованием общепринятых соглашений, а именно – слева направо и сверху вниз. Каждый конец ассоциации называется ролью. Роль дополнительно может иметь следующие характеристики: кратность, имя и направление связи. Кратность (multiplicity) определяет, сколько экземпляров класса А может быть ассоциировано с одним экземпляром класса. В таблице 6 представлен список стандартных ассоциаций, используемых при составлении проектной документации.


Таблица 6

Список стандартных ассоциаций


Категория

Примеры

А является транзакцией, ко-
торая связана с другой тран-
закцией В

CashPayment-Sale (Платеж наличными-Прода-

жа)

Reservation-Cancellation (Заказ билета-Отмена
заказа)

А является элементом тран-
закции

SalesLineltem-Sale (Элемент продажн-Прода-

жа)

А является товаром или услу-
гой для транзакции В

Item-SalesLineltem (Элемент-Элемент прода-
жи)

Flight-Reservation (Рейс-Резервирование)

А является ролью, связанной
с транзакцией В

Customer-Payment (Покупатель-Платеж)
Passenger-Ticket (Пассажир-Билет)

А является физической или
логической частью В

Drawer-Register (Устройство печати торговых
чеков-Реестр)

Seat-Airplane (Место-Самолет)

А физически или логически
содержится в В

Register-Store (Реестр-Магазин)
Item-Shelf (Товар-Полка)

А является описанием В

ProcluctDescription-Item (Описание товара-То-
вар)

А известен/зарегистрирован/
записан/включен в В

Sale-Register (Продажа-Реестр)
Reservation-FlightManifest (Заказ бнлета-Декла-
рация)

А является членом В

Cashier-Store (Кассир-Магазин)

А является организационной
единицей В

Department-Store (Отдел-Магазин)

А использует, управляет или
владеет В

Cashier-Register (Кассир-Реестр)

А следует за В

SalesLineltem- SalesLineltem (Наименование
товара- Следующее наименование товара)



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


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


Композиция, или композитная агрегация, является строго определенным типом связи целое - часть. Отношение композиции предполагает, что


1) экземпляр части в каждый момент времени принадлежит только одному целому;

2) часть всегда принадлежит целому;

3) целое ответственно за создание и удаление своих частей – либо через самостоятельное создание/удаление, либо через взаимодействие с другими объектами. При уничтожении композитного объекта его части должны быть либо уничтожены, либо присоединены к другому композитному объекту. Для обозначения композиции в UML используется закрашенный ромб на линии ассоциации со стороны целого. Необходимо идентифицировать атрибуты концептуальных классов, для которых определены соответствующие требования или для которых необходимо хранить определенную информацию.


^ ОПРЕДЕЛЕНИЕ ОСНОВНЫХ ФУНКЦИЙ СИСТЕМЫ


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

Таблица 7

^ Пример описания функций



№

Функции

Тип

1.

Поддержка базы данных.

скрытая

2.

Регистрация информации об операциях

очевидная

3.









^ ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ


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


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

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

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

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

Чтобы объяснить семантику взаимодействия, покажите свойства каждого сообщения (например, его параметры). На рисунке 6 представлен пример диаграммы последовательности для

прецедента Оформление продажи.


Простой сценарий Оформление

продажи с оплатой наличными

1. Покупатель подходит к кассовому

аппарату POS-системы с выбранными

товарами.

2. Кассир открывает новую продажу.

3. Кассир вводит идентификатор товара.

4. Система записывает идентификатор

товара и выдает его описание, цену и

общую стоимость.

Кассир повторяет действия, описанные в

пп. 3-4, для каждого наименования

товара.

5. Система вычисляет общую стоимость

покупки с налогом.

6. Кассир сообщает покупателю общую

стоимость и предлагает оплатить покупку.

7. Покупатель оплачивает покупку,

система обрабатывает платеж.





Рис. 6. Диаграмма последовательности прецедента Оформление продажи


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

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


^ ЭТАП ПРОЕКТИРОВАНИЯ


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

данных.


Понятие проектирования можно разделить на объектно-ориентированное проектирование (object-oriented design) и проектирование базы данных (database design).


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


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


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


^ СИСТЕМНЫЕ ОПЕРАЦИИ


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


Определите системные операции из диаграмм последовательностей.

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

При описании постусловий используйте следующие категории.




Создание и удаление экземпляра

Модификация атрибута

Формирование и разрыв ассоциации


Предусловия (preconditions) – это перечень предпосылок, которые всегда должны выполняться до начала сценария прецедента. Выполнение этих условий не проверяется в рамках логики выполнения данной операции, а предполагается, что они истинны.


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


Ниже в таблице 9 представлен шаблон описания системных операций.

Таблица 9

Шаблон описания системной операции


Операция

Имя операции и ее параметры

Ссылки

Прецеденты, в рамках которых может выполняться эта опера-
ция

Предусловия

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

Постусловия

Это самый важный раздел. Состояние объектов модели пред-
метной области после завершения операции.


Пример описания системной операции приведен ниже для операции
enter It em (табл. 10).

Таблица 10

Описание системной операции enterltem


Операция

enterltem (itemID: ItemlD. quantity: integer)

Ссылки

Прецеденты: Оформление продажи

Предусловия

Инициирована продажа

Постусловия

• создан экземпляр sli класса SalesLineltem

• экземпляр sli связан с текущим экземпляром класса Sale

• атрибуту sli.quantity присвоено значение quantity

• экземпляр sli связан с классом ProductDescription на осно-
ве соответствия идентификатора товара itemID



^ РЕАЛЬНЫЕ ПРЕЦЕДЕНТЫ


Реальный прецедент описывает конкретное проектное решение по реализации идеального прецедента в терминах выбранной технологии. Описание реальных прецедентов аналогично описанию идеальных прецедентов (табл. 11).

Таблица 11

Шаблон описания реального прецедента


Название прецедента

Осмысленное название, определяющее основную функ-
цию прецедента

Исполнители

Лицо, инициирующее и реализующее работу сценария

Цель

Основное назначение выполнения прецедента

Описание

Типичный ход событий, который приводит к успешно-
му завершению сценария

Тип

Тип прецедента: идеальный либо реальный

Ссылки

Ссылки на функции и идеальные прецеденты, которые
выполняет система в ходе реального прецедента


Пример описания реального прецедента приведен ниже для прецедента
Оформление продажи (табл. 12).

Таблица 12

Описание реального преце