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

Вид материала

Содержание

Реальные прецеденты
Диаграммы кооперации
Шаблоны распределения обязанностей
Диаграмма состояний
Событие (event) – это значимое или заслуживающее внимания происшествие. Состояние
Диаграмма классов
2.7. Диаграмма развертывания
Список используюмый литературы

Подобный материал:

1 2 3

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

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

Таблица 11

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

Название прецедента	Осмысленное название, определяющее основную функ- цию прецедента
Исполнители	Лицо, инициирующее и реализующее работу сценария
Цель	Основное назначение выполнения прецедента
Описание	Типичный ход событий, который приводит к успешно- му завершению сценария
Тип	Тип прецедента: идеальный либо реальный
Ссылки	Ссылки на функции и идеальные прецеденты, которые выполняет система в ходе реального прецедента

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

Таблица 12

Описание реального прецедента Оформление продажи

Название прецедента	Оформление продажи
Исполнители	Кассир
Цель	Оформить продажу товара
Описание	Ввести идентификатор товара и его количество, после этого нажать кнопку «Ввод товара». Повторять дей- ствия до тех пор. пока не будет введена информация обо всех приобретаемых товарах. Затем нажать кнопку «Оплатить».
Тип	Реальный
Ссылки	Функции: 1.8. Прецеденты: Оформление продажи

Ниже приведен пример интерфейсной формы для прецедента Оформление продажи (рис. 7). Интерфейсные формы имеет смысл составлять для
каждого реального прецедента.

Рис. 7. Интерфейсная форма для прецедента Оформление продажи

ДИАГРАММЫ КООПЕРАЦИИ

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

Моделирование реализации операции осуществляется так:

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

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

Таблица 13

Сравнительная характеристика типов диаграмм взаимодействия

Тип диаграммы	Преимущества	Недостатки
Последовательностей	Ясно отображает последо- вательность и временной порядок сообщений. Бога- тый набор обозначений.	Расширяется вправо при добавлении новых объек- тов: занимает много ме- ста по горизонтали.
Кооперации	Экономия пространства — возможность добавления объектов в двух направле- ниях.	Сложнее отследить по- следовательность сооб- щений. Более бедная си- стема обозначений.

Опишем последовательность операции makePayment:

Сообщение makePayment передается экземпляру объекта Register. Отправитель сообщения не определен.
Объект Register передает сообщение makePayment экземпляру объекта
Sale.
Объект Sale создает экземпляр объекта Payment.

На рисунках 8 и 9 представлена диаграмма последовательности make-Payment и диаграмма кооперации makePayment соответственно. Таким образом. вы можете видеть различия диаграмм взаимодействия.

Рис. 8. Диаграмма последовательности makePayment

Таким образом, код класса Sale и его метода makePayment будет выглядеть следующим образом:

public class Sale

{

private Payment payment;

public void makePayment (Money cashTendered)

{

payment = new Payment (cashTendered);

//

}

//

}

Рис. 9. Диаграмма кооперации makePayment

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

ШАБЛОНЫ РАСПРЕДЕЛЕНИЯ ОБЯЗАННОСТЕЙ

Шаблон – это именованная пара проблема - решение, содержащая рекомендации для применения в различных конкретных ситуациях. Наиболее широко известны шаблоны GRASP (шаблоны распределения обязанностей) и GoF (Gang-of-Four, шаблоны проектирования союза четырех). Шаблоны GRASP определяют базовые принципы распределения обязанностей, а шаблоны GoF – более сложные идеи проектирования. Всего в состав GRASP входит 9 шаблонов (см. табл.14).

Таблица 14

Краткое описание шаблонов распределения обязанностей

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

Продолжение табл. 14
Шаблон	Описание
Controller	Выполнение системных операций должен координиро- вать (контролировать) класс, не относящийся к уровню интерфейса пользователя и удовлетворяющий одному из следующих условий. • Класс представляет всю систему, корневой объект, устройство или подсистему в целом (внешний контроллер) • Класс представляет некоторый сценарий прецеден- та. в процессе выполнения которого выполняются системные операции (контроллер прецедента или контроллер сеанса)
Low Coupling	Чтобы снизить влияние изменений, обязанности должны распределяться таким образом, чтобы степень связанно- сти оставалась низкой.
High Cohesion	Чтобы обеспечить сфокусированность обязанностей объектов, простоту их интерфейсов, возможность управ- ления сложностью и обеспечение низкого связывания, обязанности должны распрелеляться таким образом, что- бы степень зацепления оставалась высокой.
Polymorphism	Если поведение объектов одного типа (класса) может из- меняться. обязанности распределяются для различных вариантов поведения с использованием полиморфных операций для этого ктасса
Pure Fabrication	Если у разработчика возникли проблемы, как можно обеспечить реализацию шаблонов High Cohesion и Low Coupling, создается искусственный класс, не представ- ляющий конкретного понятия из предметной области, т.е. синтезируется искусственная сущность для поддерж- ки высокого зацепления, слабого связывания и повтор- ного использования
Indirection	Чтобы обеспечить отсутствие прямого связывания, вво- дится промежуточный объект дтя обеспечения связи между другими компонентами или службами, которые не связаны между собой напрямую
Protected Variations	Чтобы распределить обязанности между объектами, под- снстемами и системами так. чтобы вариации или неста- бильность их элементов не оказывала отрицательного влияния на другие элементы, необходимо ндентифицир конкретные нестабильные точки. Обязанности распреде- ляются таким образом, чтобы вокруг этих точек быт со- здан «стабильный» интерефейс

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

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

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

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

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

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

Событие (event) – это значимое или заслуживающее внимания происшествие.

Состояние (state) – условие, характеризующее объект в некоторый момент между двумя состояниями.

Переход (transition) – это такое отношение между двумя состояниями, которые указывает на переход объекта из одного состояния в другое при выполнении некоторого события.

Рис. 10. Диаграмма состояний для прецедента Выполнения услуг.

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

Диаграммы классов являются центральным звеном объектно-ориентированных методов. Они иллюстрируют взаимоотношения программных элементов, а не понятий из предметной области. На рисунке 11 приведен пример диаграммы классов для системы NextGen.

Рис.11. Диаграмма классов информационной системы Компьютерного магазина AMSH Entr..

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

1. Выделите программные классы.

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

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

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

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

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

Рис. 555. Диаграмма развертывания

ЗАКЛЮЧЕНИЕ

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

До сих пор не решен вопрос юридической полноценности электронного документа, хотя de facto такой вид документов широко применяется. Кроме того, для обеспечения нормального ведения взаиморасчетов на территории России необходимо создать единую национальную систему расчетов на основе клиринга по типу систем CHIPS, CHAPS и др. Эта же проблема распространяется и на межгосударственные расчеты между банками стран СНГ, хотя за рубежом, за пределами СНГ, такие расчеты уже организованы в рамках SWIFT-2.

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

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

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

Учебное пособие «Теория систем и системный анализ», С.Н. Павлов, Томск: Томский межвузовский центр дистанционного образования, 2003, 134 с.
Учебное методическое пособие «Теория систем и системный анализ», Томск: Томский межвузовский центр дистанционного образования, 2003, 34 с.
Учебное пособие «Модели и проектирование баз данных», В.Д. Сибилев, Томск, 2002.
Интернет-университет информационных технологий, курс «Проектирование информационных систем», ссылка скрыта .
«Бизнес-процессы, основные стандарты их описания», С.М. Ковалев, журнал «Справочник экономиста» №11’2006.
«Особенности автоматизации конструкторского и технологического проектирования в мебельном производстве», Павел Бунаков, журнал «САПР и графика» №7’2007.
«Автоматизация предприятия. С чего начать?», Илья Коломин, журнал «Фабрика мебели», №№ 1-4' 2006.
Курс ЦИТ «Internet-технологии в проектах с пластиковыми карточками». В. Завалеев, «Центр», 1998.
«Информационные Технологии: Теория и практика рекламы в России». И. Крылов, «Центр», 1996.
«Network Magazine», №10, 1999.
«PC WEEK», №6, 1998.
Информация с Веб-сайта «Электронные платежные системы», y.ru
Информация с Веб-сайта «Банк рефератов», eferatov.ru

Blog

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

Содержание