|
i>в форме диаграммы кооперации (collaboration diagram), которая отражает структурную организацию объектов, принимающих или отправляющих сообщения. На диаграмме кооперации показано множество объектов, связи между ними и сообщения, которые они посылают или получают.Диаграммы последовательностей и кооперации относятся к динамическому виду системы. Они изоморфны, то есть их можно преобразовывать друг в друга без потери информации. Поэтому мною в работе будет рассмотрена лишь диаграмма последовательности, из которой при желании можно получить и кооперацию объектов.Для диаграммы последовательности ключевым моментом является динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно представлено слева направо в виде линии жизни (lifeline) (период времени существования) отдельного объекта, участвующего во взаимодействии, а второе - вертикальной временной осью, направленной сверху вниз. Взаимодействие объектов реализуется посредством сообщений, посылаемые одними объектами другим. Сообщения появляются в том порядке, в котором они показаны - сверху вниз. Заключение договора:Рис.16. Диаграмма последовательности Заключение договораДля Заключения договора клиенту необходимо передать подписанный договор оператору, который в последствии открывает главное окно. Далее он должен выбрать регистрацию. Вводятся сведения в пограничный класс Окно регистрации окно составления договора, заполняет появившуюся форму. Система управления проверяет введенные данные и сохраняет договор. Затем в контейнерном классе Клиент сохраняется информация о новом клиенте.Ниже приведена диаграмма кооперации для рассмотренного варианта использования Заключение договора:Рис.17. Диаграмма кооперации Заключение договора Детализация счета:Рис.18. Диаграмма последовательности Детализация счетаОператор открывает главное окно системы, затем окно документа, а именно окно детализации счета. Далее формирует отчет путем передачи сообщения управляющему классу Система управления критерии времени. В окне детализации отображается перечень всех звонков, удовлетворяющих требованию клиента. Документ, отобразившийся в окне, оператор может распечатать.Ниже приведена диаграмма кооперации для рассмотренного варианта использования. Блокировка номера:Рис. 19. Диаграмма последовательности Блокировка номераОператор открывает главное окно системы, затем окно документа, а именно окно блокировки. Далее путем передачи сообщения управляющему классу Система управления, блокирует номер. Система управления выполняет заданный запрос, сохраняет свои действия и информирует об этом.Ниже приведена диаграмма кооперации для рассмотренного варианта использования.Блокировка номера:Рис. 20. Диаграмма кооперации Блокировка номера 2.5 Моделирование состоянийСледующим этапом разработки является моделирование состояний, необходимая информация для которого содержится в модели классов-сущностей и модели взаимодействий. Модель классов представляет классы, которые подлежат анализу на предмет выявления нетривиального поведения, а модель взаимодействий помогает определить методы, которые могут влиять на изменение состояний классов.Состояние можно рассматривать как отдельную ситуацию, в течение которой имеет место выполнение некоторого условия. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.Следует заметить, что не каждый атрибут класса может характеризовать его состояние. Как правило, имеют значение только такие свойства элементов системы, которые отражают динамический или функциональный аспект ее поведения.Диаграммы состояний (Statechart Diagram) определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса и отражают динамику поведения единственного объекта.Не следует строить диаграммы состояний для каждого класса в системе; их стоит использовать только для тех классов, поведение которых действительно интересует, и построение диаграмм состояний помогает лучше его понять. На основании анализа проектируемой системы и требований к ней, можно сказать, что интересным разработчику представляется поведение класса Договор. Рассмотрю диаграмму состояний для этого класса.Рис.21. Диаграмма состояний для класса "Договор"Перед созданием Договора он приобретает состояние Новый. При подписании договора обеими сторонами переходит в состояние Подписан. Действителен он будет до срока действия, после чего он может перейти в состояние Продлен либо Просрочен, Расторгнут и, соответственно, перейдет в состояние Удален. Рис.22. Диаграмма состояний для класса "Заявление"Перед созданием и в процессе создания заявления, он приобретает состояние Новый. После подписи клиентом переходит в состояние Заполненное. При передаче его оператору, заявление переходит с состояние На рассмотрении. Если на стадии рассмотрения обнаружены ошибки, то заявление переходит в состояние Отвергнут, иначе - в состояние На обработке. При удовлетворении заявления он Исполнен, в противном случае - отвергнут.2.6 Проектирование статической структурыСтатическая структура информационной системы представляет собой конечную диаграмму классов, на которой представлено взаимодействие сущностей, управляющих и пограничных классов, выявленных на начальном этапе проектирования и в процессе моделирования взаимодействий. Модель взаимодействий служит источником информации не только о том, какие классы, помимо сущностей, выявленных в начале разработки, должны существовать в системе, но и о том, как они взаимодействуют и связаны друг с другом, а также какими методами они обладают.На диаграммах ниже статическая структура представлена в двух частях. Первая иллюстрирует взаимодействие управляющего класса с сущностями, а вторая - взаимодействие управляющего класса с пограничными. Рис.23. Статическая структура ИС (часть 1) Рис.24. Статическая структура ИС (часть 2) Не все модели последовательностей и кооперации были построены с учетом принципа трехслойного взаимодействия (что, возможно, является недостатком данной разработки), поэтому на конечной диаграмме классов должны присутствовать связи между некоторыми пограничными классами и сущностями. Однако ввиду того, что при отображении всех этих связей на одной диаграмме ее практически невозможно будет читать, она в работе не приводится 2.7 Проектирование пользовательского интерфейсаПосле завершения предыдущих этапов разработки имею всю необходимую информацию для того, чтобы приступить к следующему не менее важному - к проектированию пользовательского интерфейса.Пользователи программ, как правило, не разделяют функциональность и пользовательский интерфейс. Для пользователей именно пользовательский интерфейс является программой. Для них, если интерфейс хороший, стало быть, и сама программа хороша и удобна.Пользовательский интерфейс часто понимают только как внешний вид системы. В действительности пользовательский интерфейс включает в себя все аспекты дизайна, которые оказывают влияние на взаимодействие пользователя и системы. Это не только экран, который видит пользователь. Пользовательский интерфейс состоит из множества составляющих, таких как набор задач пользователя, которые он решает при помощи системы, элементы управления системой, навигация между блоками системы, визуальный (и не только) дизайн экранов программы. При проектировании пользовательского интерфейса я опиралась на модель взаимодействий, которая предоставляет информацию о том, какие окна (в данном случае формы) отображаются в ответ на то или иное действие пользователя и какие элементы в них должны содержаться. Кроме того, разработку пользовательского интерфейса я постарался провести с учетом принципов проектирования интерфейса. При построении в интерфейсе были использованы термины и понятия, доступные и понятные будущим пользователям системы. Я сделать так, чтобы разные, но однотипные операции проводились аналогичным способом. Кроме того, интерфейс предоставляет необходимую информацию в случае возникновения каких-либо ошибок. Вся информация о сообщениях об ошибках также представлена на моделях взаимодействий. Ввиду большого объема работы мною была спроектирована лишь часть пользовательского многодокументного интерфейса. Далее результат выполнения этого этапа проектирования.Рис.25. Модель интерфейса для заключения договора Так как интерфейс программы многодокументный, то все дочерние окна открываются и сворачиваются в родительском окне в свободной площади. Дочерние окна могут не открываться, выноситься вне родительского. Меню - в данном компоненте содержатся все основные команды доступные пользователю при работе с системой. Панель инструментов - на этом графическом элементе размещены кнопки, ассоциированные с наиболее часто применяемыми командами. 2.8 Диаграмма компонентовДля создания конкретной физической системы необходимо реализовать все элементы логического представления в конкретные материальные сущности. Для описания таких реальных сущностей предназначено физическое представление модели. Базовыми элементами физического представления системы в нотации UML являются компоненты, которые представляют собой физически существующие части системы, которые обеспечивают реализацию классов и отношений, а также функционального поведения моделируемой программной системы.На рисунке 26 показан результат попытки, определить состав компонентов системы и представить их в виде диаграммы компонентов. Рис.26. Диаграмма компонентов2.9 Проектирование архитектуры приложенияТехнология клиент-сервер по праву считается одним из "китов", на которых держится современный мир компьютерных сетей.Для проектирования архитектуры данного приложения я безусловно использую технологию клиент-сервер. Что же касается архитектуры, двухуровневая или трех, то здесь есть над чем порассуждать. Итак, термин "клиент-сервер" означает такую архитектуру программного комплекса, в которой его функциональные части взаимодействуют по схеме "запрос-ответ". Если рассмотреть две взаимодействующие части этого комплекса, то одна из них (клиент) выполняет активную функцию, т.е. инициирует запросы, а другая (сервер) пассивно на них отвечает. По мере развития системы роли могут меняться, например некоторый программный блок будет одновременно выполнять функции сервера по отношению к одному блоку и клиента по отношению к другому.Замечу, что любая информационная система должна иметь минимум три основные функциональные части - модули хранения данных, их обработки и интерфейса с пользователем, в моем случае с оператором. Каждая из этих частей может быть реализована независимо от двух других. Например, не изменяя программ, используемых для хранения и обработки данных, можно изменить интерфейс с оператором таким образом, что одни и те же данные будут отображаться в виде таблиц, графиков или гистограмм. Не меняя программ представления данных и их хранения, можно изменить программы обработки, например, изменив алгоритм полнотекстового поиска. И наконец, не меняя программ представления и обработки данных, можно изменить программное обеспечение для хранения данных, перейдя, например, на другую файловую систему.В классической архитектуре клиент-сервер приходится распределять три основные части приложения по двум физическим модулям. Обычно ПО хранения данных располагается на сервере (например, сервере базы данных), интерфейс с пользователем - на стороне клиента, а вот обработку данных приходится распределять между клиентской и серверной частями. В этом-то и заключается основной недостаток двухуровневой архитектуры, из которого следуют несколько неприятных особенностей, сильно усложняющих разработку клиент-серверных систем.При разбиении алгоритмов обработки данных необходимо синхронизировать поведение обеих частей системы. Все разработчики должны иметь полную информацию о последних изменениях, внесенных в систему, и понимать эти изменения. Это создает большие сложности при разработке клиент-серверных систем, их установке и сопровождении, поскольку необходимо тратить значительные усилия на координацию действий разных групп специалистов. В действиях разработчиков часто возникают противоречия, а это тормозит развитие системы и вынуждает изменять уже готовые и проверенные элементы.Чтобы избежать несогласованности различных элементов архитектуры, пытаются выполнять обработку данных на одной из двух физических частей - либо на стороне клиента ("толстый" клиент), либо на сервере ("тонкий" клиент). Каждый подход имеет свои недостатки. В первом случае неоправданно перегружается сеть, поскольку по ней передаются необработанные, а значит, избыточные данные. Кроме того, усложняется поддержка системы и ее изменение, так как замена алгоритма вычислений или исправление ошибки требует одновременной полной замены всех интерфейсных программ, а иначе могут возникнуть ошибки или несогласованность данных. Если же вся обработка информации выполняется на сервере (когда такое вообще возможно), то возникает проблема описания встроенных процедур и их отладки. Дело в том, что язык описания встроенных процедур обычно является декларативным и, следовательно, в принципе не допускает пошаговой отладки. Кроме того, систему с обработкой информации на сервере абсолютно невозможно перенести на другую платформу, что является серьезным недостатком.Большинство современных средств быстрой разработки приложений (RAD), которые работают с различными базами данных, реализует первую стратегию, т.е. "толстый" клиент обеспечивает интерфейс с сервером базы данных через встроенный SQL. Такой вариант реализации системы с "толстым" клиентом, кроме перечисленных выше недостатков, обычно обеспечивает недопустимо низкий уровень безопасности. Например, в банковских системах приходится всем операционистам давать права на запись в основную таблицу учетной системы. Кроме того, данную систему почти невозможно перевести на Web-технологию, так как для доступа к серверу базы данных используется специализированное клиентское ПО.Итак, рассмотренные выше модели имеют следующие недостатки.1. "Толстый" клиент:сложность администрирования;усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе;усложняется распределение полномочий, так как разграничение доступа происходит не по действиям, а по таблицам;перегружается сеть вследствие передачи по ней необработанных данных;слабая защита данных, поскольку сложно правильно распределить полномочия.2. "Толстый" сервер:усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО и нет хороших средств отладки;производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;получившиеся таким образом программы полностью непереносимы на другие системы и платформы.Для решения перечисленных проблем использую трехуровневую архитектур клиент-сервер.В трехуровневой архитектуре "тонкий" клиент не перегружен функциями обработки данных, а выполняет свою основную роль системы представления информации, поступающей с сервера приложений. Трехуровневая архитектура клиент-сервер позволяет более точно назначать полномочия операторов, так как они получают права доступа не к самой базе данных, а к определенным функциям сервера приложений. Это повышает защищенность системы (по сравнению с обычно архитектурой) не только от умышленного нападения, но и от ошибочных действий персонала.Для примера рассмотрю систему, различные части которой работают на нескольких удаленных друг от друга серверах. Допустим, что от разработчика поступила новая версия системы, для установки которой в двухуровневой архитектуре необходимо одновременно поменять все системные модули. Если же этого не сделать, то взаимодействие старых клиентов с новыми серверами может привести к непредсказуемым последствиям, так как разработчики обычно не рассчитывают на такое использование системы. В трехуровневой архитектуре ситуация упрощается. Дело в том, что поменяв сервер приложений и сервер хранения данных (это легко сделать одновременно, так как оба они обычно находятся рядом), мы сразу меняем набор доступных сервисов. Таким образом, вероятность ошибки из-за несоответствия версий серверной и клиентской частей резко сокращается. Если в новой версии какой-либо сервис исчез, то элементы интерфейса, обслуживавшие его в старой системе, просто не будут работать. Следует отметить и тот факт, что в трехуровневой системе по каналу связи между сервером приложений и базой данных передается достаточно много информации. Однако это не замедляет вычислений, так как для связи указанных элементов можно использовать более скоростные линии. Это потребует минимальных затрат, поскольку оба сервера обычно находятся в одном помещении. Таким образом, увеличивается суммарная производительность системы - над одной задачей теперь работают два различных сервера, а связь между ними можно осуществлять по наиболее скоростным линиям с минимальными затратами средств.Рис.27. Диаграмма развертывания ЗаключениеВ результате проделанной мною работы была спроектирована имитационная модель информационной системы "Центр обслуживания абонентов".В процессе работы были созданы модели вариантов использования, классов-сущностей, видов деятельности, взаимодействий, состояний, статической структуры, пользовательского интерфейса, компонентов, и архитектуры приложения.Хочу отметить, что разработанный проект далеко не является полным и готовым к реализации. В процессе разработки были рассмотрены и смоделированы основные функции системы. Но помимо рассмотренных, система должна поддерживать еще и другие функции. Следует сказать, что плохо проработана диаграмма компонентов, однако это можно объяснить тем, что для определения состава компонентов, из которых должна состоять система, необходим очень большой объем знаний, на приобретение которого практически не было времени.Дипломная работа был выполнена с использованием case-средств BPWin 4.0 и IBM Rational Rose 2003. ГлоссарийCASE (Computer-Aided Software/System Engineering) - средства автоматизации методологий структурного системного анализа и проектированияСУБД - система управления базами данныхБД - база данныхТфОП - телефонной сети общего пользованияSADT (Structured Analysis and Design Technique) - технология структурного анализа и проектирования и ее подмножество стандарт IDEF0DFD (Data Flow Diagrams) - диаграммы потоков данныхERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь"STD (State Transition Diagrams) - диаграммы переходов состояний.ПО - программное обеспечение Библиография1. Д.Н. Столбовский. Лекции по проектированию экономических информационных систем. 2. Леоненков. Самоучитель UML. 3. Е.Б. Золотухина, Р.В. Алфимов (c) Interface Ltd., 2001. 4. Доклад компании Yphise "UML-моделирование информационных систем и проектов" ("UML Modeling of Projects and Information Systems") /www.interface.ru/ 5. Липаев В.В. "Качество программного обеспечения". - М.: "Финансы и статистика", 1993. 6. Боэм Б.У. "Инженерное проектирование программного обеспечения". - М.: "Радио и связь", 1985. 7. "Технико-экономическое обоснование дипломных проектов" под редакцией проф. В.К. Беклешова. - М.: "Высшая школа", 1991. 8. Костров А.В. "Основы информационного менеджмента": Учебное пособие. - М.: Финансы и статистика, 2001. 9. Классификационный справочник должностей служащих. - М.: ИНФРА-М, 2001.
Страницы: 1, 2, 3, 4
|
