Дипломная работа: Автоматизация "личного кабинета" консультанта по недвижимости (на примере организации Росинформ)

Скачать

Заказать новую работу

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
33
ГЛАВА 2. ПРОЕКТИРОВАНИЕ СИСТЕМЫ
В области создания и эксплуатации программных систем
основополагающими методиками и концепциями, обеспечивающими
интегрированный взгляд на сложный комплекс вопросов, являются
представления об архитектуре и стратегии информационных технологий.
Действительно, развитие информационных технологий привело к
возникновению нового типа бизнеса – электронного, и поставило новые задачи:
обеспечить интеграцию отдельных компонентов информационных систем в
рамках одного предприятия, а также взаимодействие информационных систем
разных организаций. Практически ни в одной отрасли не удается решить все
задачи путем внедрения одной, даже очень мощной, системы управления. Так
что наличие нескольких систем от разных поставщиков стало правилом, а не
исключением. Появляется задача оптимального выбора таких компонент и
построения необходимой для их работы инфраструктуры.
Это происходит в условиях, когда мы наблюдаем растущую сложность
технологических решений, необходимость интеграции большого количества
технологий с целью обеспечения растущих потребностей бизнеса, государства
и общества в целом – они во все большей степени полагаются на технологии в
своей повседневной деятельности. Такая сложность часто приводит к
катастрофическому увеличению количества неудач в проектах, связанных с
внедрением информационных систем. По оценкам различных консалтинговых
компаний, примерно 50% ИТ-проектов в различных отраслях заканчиваются не
так, как запланировано, а в государственном секторе этот процент достигает
70%. Из этого количества примерно треть неудач связана с проблемами
проектирования архитектуры.
При этом экспоненциально растущая сложность задачи развития
информационных систем предприятий больше не может решаться за счет
механического увеличения персонала информационных технологий. По
данным аналитической компании Butler Group, крупная организация
34
эксплуатирует в среднем около 40 критически важных прикладных систем.
Известен и такой факт. Служба ИТ одного из крупнейших российских банков
поддерживает работу около 300 различных прикладных систем. Наличие
нескольких сотен прикладных систем – скорее правило, чем исключение для
органов власти регионального уровня. Можно ли эффективно управлять всем
этим хозяйством, не имея целостного архитектурного взгляда?
На сегодняшний день считается, что архитектура программной системы
наиболее оптимально может быть описана с помощью пяти взаимосвязанных
видов или представлений, каждый из которых является одной из возможных
проекций организации и структуры системы и заостряет внимание на
определенном аспекте ее функционирования:
1. вид с точки зрения прецедентов (use case view) охватывает
прецеденты, которые описывают поведение системы, наблюдаемое конечными
пользователями, аналитиками и тестерами. Этот вид специфицирует не
истинную организацию программной системы, а те движущие силы, от которых
зависит формирование системной архитектуры;
2. вид с точки зрения проектирования (design view) охватывает
классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения.
Этот вид подчеркивает прежде всего функциональные требования,
предъявляемые к системе, то есть те услуги, которые она должна предоставлять
конечным пользователям;
3. вид с точки зрения процессов (process view) охватывает нити и
процессы, формирующие механизмы параллелизма и синхронизации в системе.
Этот вид описывает главным образом производительность, масштабируемость
и пропускную способность системы.
4. вид с точки зрения реализации (implementation view) охватывает
компоненты и файлы, используемые для сборки и выпуска конечного
программного продукта. Этот вид предназначен в первую очередь для
управления конфигурацией версий системы, составляемых из независимых (до
35
некоторой степени) компонентов и файлов, которые могут по-разному
объединяться между собой;
5. вид с точки зрения развертывания (deployment view) охватывает
узлы, формирующие топологию аппаратных средств системы, на которой она
выполняется. В первую очередь он связан с распределением, поставкой и
установкой частей, составляющий физическую систему.
Каждый из перечисленных видов может считаться вполне
самостоятельным, так что члены группы проекта, могут сосредоточиться на
изучении только тех аспектов архитектуры, которые непосредственно их
касаются. Правда, нельзя забывать о том, что эти виды взаимодействуют друг с
другом, что неудивительно, так как они представляют разные взгляды на одну
систему. Например, узлы вида с точки зрения развертывания содержат
компоненты, описанные для вида сточки зрения реализации, а те в свою
очередь представляют физическое воплощение классов, интерфейсов,
коопераций и активных классов из видов с точки зрения проектирования и
процессов
В этой главе приведено описание результатов проектирования
архитектуры системы. В ходе логического проектирования (Глава 2) выделены
основные объекты будущей системы и связи между ними. На этапе
физического проектирования разработаны детальные инструкции, которые
можно использовать при реализации системы автоматизации.
2.1. Физическая модель
Все рассмотренные ранее диаграммы отражали концептуальные и
логические аспекты построения модели системы. Особенность логического
представления заключается в том, что оно оперирует понятиями, которые не
имеют материального воплощения. Другими словами, различные элементы
логического представления, такие как классы, ассоциации, состояния,
сообщения, не существуют материально или физически. Они лишь отражают
36
понимание статической структуры той или иной системы или динамические
аспекты ее поведения.
Для создания конкретной физической системы необходимо реализовать
все элементы логического представления в конкретные материальные
сущности. Для описания таких реальных сущностей предназначен другой
аспект модельного представления, а именно – физическое представление
модели. В контексте языка UML это означает совокупность связанных
физических сущностей, включая программное и аппаратное обеспечение.
Физическая система (physical system) — реально существующий
прототип модели системы.
С тем чтобы пояснить отличие логического и физического
представлений, необходимо в общих чертах рассмотреть процесс разработки
программной системы. Ее исходным логическим представлением могут
служить структурные схемы алгоритмов и процедур, описания интерфейсов и
концептуальные схемы баз данных. Однако для реализации этой системы
необходимо разработать исходный текст программы на языке
программирования. При этом уже в тексте программы предполагается
организация программного кода, определяемая синтаксисом языка
программирования и предполагающая разбиение исходного кода на отдельные
модули.
Однако исходные тексты программы еще не являются окончательной
реализацией проекта, хотя и служат фрагментом его физического
представления. Программная система может считаться реализованной в том
случае, когда она будет способна выполнять функции своего целевого
предназначения. А это возможно, только если программный код системы будет
реализован в форме исполняемых модулей, библиотек классов и процедур,
стандартных графических интерфейсов, файлах баз данных. Именно эти
компоненты являются базовыми элементами физического представления
системы в нотации языка UML.
37
Полный проект программной системы представляет собой совокупность
моделей логического и физического представлений, которые должны быть
согласованы между собой. В языке UML для физического представления
моделей систем используются так называемые диаграммы реализации, которые
включают в себя две отдельные диаграммы: диаграмму компонентов и
диаграмму развертывания.
2.2. Диаграммы компонентов
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм,
описывает особенности физического представления системы и отражает
архитектурные решения относительно программных модулей. Диаграмма
компонентов позволяет определить архитектуру разрабатываемой системы,
установив зависимости между программными компонентами, в роли которых
может выступать исходный, бинарный и исполняемый код. Во многих средах
разработки модуль или компонент соответствует файлу. Пунктирные стрелки,
соединяющие модули, показывают отношения взаимозависимости,
аналогичные тем, которые имеют место при компиляции исходных текстов
программ. Основными графическими элементами диаграммы компонентов
являются компоненты, интерфейсы и зависимости между ними.
Диаграмма компонентов обеспечивает согласованный переход от
логического представления к конкретной реализации проекта в форме
программного кода. Одни компоненты могут существовать только на этапе
компиляции программного кода, другие – на этапе его исполнения. Диаграмма
компонентов отражает общие зависимости между компонентами, рассматривая
последние в качестве отношений между ними.
Компоненты
Для представления физических сущностей в языке UML применяется
специальный термин – компонент.
Источник: https://baza.diplomsite.ru/previewfile/2504

Смотрите также:

ЦЕНОВАЯ ПОЛИТИКА ПРЕДПРИЯТИЯ НА ПРИМЕРЕ ООО «ДНС РИТЕЙЛ»
_archivetempпротивовоспалительные
- Обратный порядок следования фаз 4
- Сопротивление изоляции 25
!_Лабораторные_работы_1_сем_ОУТС
!Контрольная работа (задание)
!Фармакология препаратов для терапии заболеваний дыхательных путей
'Electronics Workbench' – алгоритм инструмента моделирования электронных схем
'Новая экономика': российская специфика