Министерство энергетики и промышленности республики таджикистан технологический университет таджикистана худжандский филиал «Утверждаю» Зав кафедрой
| Вид материала | Реферат |
СодержаниеКонцептуальная модель. Ассоциация (association) Определение основных функций системы Пример описания функций Диаграмма последовательностей Этап проектирования Системные операции |
- Президента Республики Таджикистан, Национальный банк Таджикистана не несет ответственность, 573.42kb.
- Инструкция №112 «О безналичных расчетах в республике Таджикистан», 543.91kb.
- Министерство образования азербайджанской республики азербайджанский технологический, 3547.02kb.
- Программа полной переработки животноводческого сырья (кожи и шерсти) в Республике Таджикистан, 627.47kb.
- Правительством Республики Таджикистан и под его гарантию, грантов, гуманитарной помощи, 177.48kb.
- Положение №118, 230.1kb.
- Россотрудничество министерство образования республики таджикистан академия образования, 7813.64kb.
- Концепция использования земель в Республике Таджикистан Содержание, 880.46kb.
- Республики таджикистан закон, 248.44kb.
- Опыт международного сотрудничества таджикистана в сфере подготовки кадров государственного, 75.54kb.
КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ.
Модель предметной области – это визуальное представление концептуальных классов или объектов реального мира в терминах предметной области. Такие модели также называют концептуальными моделями. Для создания модели предметной области необходимо выполнить следующие действия.
- Выделите концептуальные классы.
- Отобразите их в модели предметной области в виде классов на диаграмме 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 |