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

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Объктно-ориентированный анализ и проектирование системы

1.1 Описание предметной области

1.2 Инструменты разработки

2. Программная реализация

2.1 Диаграмма классов

2.2 Диаграмма прецедентов

2.3 Диаграмма состояния

2.4 Диаграмма последовательностей

3. Реализация системы

3.1 Диаграмма компонентов

3.2 Диаграмма развертывания

4. Практическое применение

Заключение

Литература

Приложение



Введение

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

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

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

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

Главной целью курсовой работы является разработка модели на объектно-ориентированном языке моделирования - Visual UML. Этот унифицированный язык является своеобразным «ключом», используя который можно легко сконструировать и визуализировать систему программного обеспечения.

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

1. В первом разделе рассмотрен объектно-ориентированный анализ системы. В нём описывается предметная область вместе с инструментами разработки;

2. Во втором разделе рассмотрено проектирование системы, описаны прецеденты диаграммы классов, последовательности и состояния;

3. Третий раздел отведён под реализацию системы. Также в нём описаны диаграммы реализации;

4. В четвёртом разделе моделируется практическое применение разрабатываемого комплекса.



1. Объктно-ориентированный анализ и проектирование системы

1.1 Описание предметной области

Целью курсовой работы является разработка модели ПО встроенного микропроцессора в учрежденческой АТС средствами UML.

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

Опишем установление телефонного соединения между абонентами. Сперва абонента А поднимает трубку телефона, после чего мини-АТС получает сигнал «Трубка», и в ответ посылает сигнал «Тон». После принятия этого сигнала, абонента А набирает телефонный номер, посылает три сигнала «Цифра». Мини-АТС проверяет, готов ли вызываемый абонент к разговору, или линия занята. Если абонент Б занят - то абонент А получает сигнал «Занято». Если же всё нормально, то мини-АТС посылает абонентам А и Б сигнал «Вызов». После чего абонент А слышит в трубке длинные гудки, а телефон абонента Б начинает звонить. Если абонент Б снимает трубку, и мини-АТС успешно получает от него сигнал «Трубка», то производится коммутация линии. Производится разговор, в ходе которого абоненты обмениваются между собой данными, которые АТС должна передать от абонента А к абоненту Б и наоборот. Разговор кончается, когда один из абонентов кладёт трубку, в результате чего АТС получает сигнал «Конец», а второй абонент получит сигнал «Тон».

Отдельно стоит описать ситуацию, при которой абонент желает установить связь с абонентом, находящимся за пределами учреждения. Абонент набирает номер «9», после чего мини-АТС отправляет по линии соединённой с городской АТС сигнал «Трубка». Данная линия будет служить для передачи «Данных» в ходе диалога. Эта линия не вносит никаких изменений в передаваемые данные, за исключением завершения сеанса. Лишь после того как мини-АТС получит от городской АТС сигнал «Конец», мини-АТС отправит абоненту сигнал «Тон» и будет ждать сигнала «Конец» для окончания обслуживания абонента. Если же вызывавший абонент решит первым положить трубку, то мини-АТС примет сигнал «Конец», и перенаправит его к городской АТС, после чего завершит сеанс.

Кроме того, мини-АТС может получить сигнал вызова от городской АТС. Это возможно лишь при отсутствии соединения с внешними абонентами. Сигнал «Вызов» от городской АТС принимается абонентом с кодом «000». Только он способен ответить на внешний звонок.

1.2 Инструменты разработки

Первое упоминание о UML датируется октябрём 1994 года, когда Джеймс Румбах и Гранди Буч из RSC (Rational Software Corporation) решили унифицировать методы OMT и Booch. Несмотря на высокую популярность обоих методов, работа была направлена в первую очередь на изучение всех известных объектно-ориентированных методов. Это делалось для объединения их достоинств. Уже в октябре 1995 года был подготовлен и опубликован проект унифицированного метода, который получил название «Unified Method». Его первая версия была версий 0.8. Вскоре после публикации над проектом также стал работать А. Джекобсон, главный технолог Objectory AB, компании родом из Швеции. Его главной целью была интеграция собственного метода (OOSE) с двумя предыдущими.

Изначально, авторы OMT, OOSE и Booch планировали создать унифицированный язык моделирования исключительно для вышеперечисленных методик. Это казалось логичным, т.к. каждый метод был множество раз проверен на практике, и «показал» собственную продуктивность при решении множественных задач ООАП. Это и дало основание для их дальнейшей модификации, с помощью устранения имеющихся несоответствий некоторых обозначений и понятий. Но в тоже время, унификация нотации и семантики должна была создать некоторую стабильность на рынке CASE средств тех дней, т.к. без этого было невозможно продвинуть соответствующих программный инструментарий. Предстоящая работа давала большие надежды на значительное улучшение всех этих методов.

Уже во время работ по унификации собственных методов, Дж. Румбах, Г. Буч и А. Джекобсон сформулировали основных требования к языку моделирования:

- С его помощью можно было бы моделировать не только ПО, но и более широкие классы бизнес-приложений и систем;

- Этот язык должен был обеспечить масштабируемость моделей, что особенно важно для сложных систем с множеством целей;

- Язык должен был обеспечить связь между базовыми понятиями физического и концептуального уровня;

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

Использование языка UML основывается на следующих общих принципах моделирования:

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

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

- Иерархическое построение - когда система описывается, необходимо использовать разные уровни для детализации и абстрагирования в рамках фиксированных представлений. Первое представление системы опишет её лишь в «общих» чертах, т.е. оно является представление концептуального уровня, а каждый следующий уровень будет раскрывать новые аспекты системы с постепенно возраждающей детализацией - и так до физического уровня. Модель физического уровня в UML языке наиболее полно и точно отражает компонентный состав проектируемой системы с точки зрения как программных, так и аппаратных платформ определённых производителей.



2. Программная реализация

2.1 Диаграмма классов

В ООАП центральной место отведено разработке логической модели в качестве диаграммы классов. В языке UML нотация классов будет проста и интуитивно понятна всем людям, имеющим опыт работы с CASE-инструментами. Аналогичная нотация используется и для экземпляров класс, с единственным различием - к имени класса добавится имя объекта, а вся надпись будет подчёркнутой.

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

Class diagram, или диаграмма классов используется для предоставления статистической структуры модели системы в терминологии классов ООП. Эта диаграмма отображает определённые взаимосвязи между отдельными сущностями предметной области, вроде подсистем и объектов. Кроме она описывает их типы отношений и внутреннюю структуру. На этой диаграмме не указывают информацию об временных аспектах функционирования системы. Т.е. основываясь на этой точке зрения - диаграмма классов есть не что иное, как дальнейшее развитие концептуальной модели проектируемой системы.

Диаграмма классов - это определённый граф, вершинами которого будут являться элементы с классом «Классификатор». Они связаны разнообразными типами структурных отношений. Нужно отметить, что в диаграмме классов также могут содержаться отношения, пакеты, интерфейсы и отдельные экземпляры вроде связей и объектов. Когда говорят о этой диаграмме, часто имеют в виду структурную статическую модель проектируемой системы. Вот почему диаграмма классов часто определяется как графическое представление таких взаимосвязей логической модели системы, на которую не влияет время.

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

Чаще всего пакет статической структурной модели можно представить, как одну или же несколько диаграмм классов. Часто, для удобства и графической визуализации структурной взаимосвязи на предметной области эту модель представляют в виду отдельных диаграмм. В этом случае компоненты диаграммы будут соответствовать элементам статистической сематической модели. Модель этой системы в свою очередь должна быть согласована с внутренней системой классов, описанной на UML языке [2].

Разработанную в соответствие с заданием курсового проекта модель диаграммы классов можно увидеть в приложении А, на рисунке А.1. На диаграмме отображены три класса: Мини АТС, АТС и телефон. Классы Телефон и Мини АТС, а также Мини АТС и АТС связаны отношениям ассоциации. Каждый из этих классов имеет определённую операции и атрибуты.



2.2 Диаграмма прецедентов

Визуальное моделирование UML - это своеобразный «спуск» по одному уровню, от предельно абстрактной и общей (Так называемой концептуальной модели) модели исходной системы до логической, и так вплоть до физической. Для того чтобы достичь этой цели сперва создаётся модель в виде диаграммы вариантов использования (use case diagram), в которой будут описаны функциональные назначения системы. Говоря более простым языком - в этой модели будет описано то, что система будет «Делать» во время своей работы. Диаграмма вариантов использования есть исходное концептуальной представление модели во время её разработки.

Прежде всего, разработка диаграммы вариантов предназначена для:

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

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

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

Вкратце суть данной диаграммы можно описать таким образом: проектируемая система представляет в множестве сущностей (Или актёров), которые взаимодействуют с системой с использованием вариантов использования. Актёром, или же действующим лицом является любая сущность, которая взаимодействует (Или будет взаимодействовать) с системой извне. Актёром может быть: Человек, техника, программа или иная любая система, которая может быть источником воздействия на моделируемую систему. Кто будет являться «актёром» - определяет разработчик. Вариант использования (Use case) используется для описания сервисов, доступ к которым актёры получат от системы. Каждый из вариантов использования будет определять своеобразный набор действий, которые совершаются системой при разговоре с актёром. Но, по поводу реализации взаимодействия меж системой и актёрами ничего не обговаривается.

В предельно «общем» случае, диаграмма вариантов использования будет представлять собой граф особого вида, который будет графической нотацией, целью которого будет являться представление определённых вариантов использования, актёров, и, возможно - определённых интерфейсов в отношении между данными элементами. Отдельные части диаграммы можно заключить в прямоугольник, в которой будет обозначена проектируемая система в общем виде. Отношения данного графа могут быть исключительно фиксированные типы взаимосвязи между вариантами использования и актёрами, в совокупности они опишут сервисы вкупе с функциональными требованиями к моделируемой системе [2].

С моделью диаграммы прецедентов, которая разработана на основе задания курсового проекта, можно ознакомиться в приложении А (Рисунок А2). На данной диаграмме приведены действия актёра «Человек» с системой. Каждый из прецедентов в данной системы связан с актёром отношением ассоциации.

2.3 Диаграмма состояния

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

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

Эта диаграмма предназначена в первую очередь для описания всех возможных переходов и последовательности состояний, которые в совокупности будут моделировать поведение элемента модели во время его жизненного цикла. В диаграмме состояний представлено динамическое поведение сущностей, созданное на основе спецификаций их реакции на восприятие определённых событий. К примеру системы, реагирующие на внешние действия пользователей и/или других систем, часто называют реактивными. Если подобные действия инициируются в случайный момент времени, то модель имеет асинхронное поведение.

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

Диаграмма состояний есть не что иное как граф специального вида, который образует своеобразный «Автомат». Понятие «Автомат» в контексте UML имеет крайне специфическую семантику, в основе которой лежит теория автоматов. В качестве вершин этого графа выступают состояния и иные типы элементов автомата (Т.е. псевдосостояния), которые отображаются с использованием соответствующих графических символов. Для обозначения перехода из одного состояния в другое используются дуги графа. Диаграммы состояний можно «вкладывать» друг в другу, создавая тем самым более детальное представление о конкретных элементах модели. Для того чтобы понять семантику выбранной диаграммы помимо особенностей поведения моделируемой сущности необходимо представлять и общие сведения о теории автоматов [2].

С моделью диаграммы состояний, разработанной в соответствии с заданием курсового проекта можно ознакомиться в приложении А на рисунке А3. На диаграмме можно увидеть следующие состояния системы: Начальное, Активное и Конечное. Помимо этого, там определены сторожевые условия и переходы меж состояниями.

2.4 Диаграмма последовательностей

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

На диаграмме последовательности отображают лишь те объекты, которые напрямую используются при взаимодействии, и не отображают потенциальных статистических ассоциаций с иными объектами. Для этой диаграммы наиболее важным моментом является «динамика» взаимодействия объектов во времени. В этом случае соответствующая диаграмма будет иметь пару измерений, первое - слева направо, представленная в виде вертикальных линий, каждая из них будет изображать линию жизни конкретного объекта, объект должен использоваться во взаимодействии. Каждый из объектов будет графически отображаться как прямоугольник, и находиться сверху собственной линии жизни. Внутрь прямоугольника записывают имя класса и имя объекта, разделяемые с помощью двоеточия. Вся запись подчёркивается - это «признак» объекта, который представляет собой экземпляр класса.

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

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

Линию жизни объекта, или же object lifetime отображают с помощью пунктирной вертикальной линии, ассоциированной с единственным объектом на диаграмме последовательности. Эта линия используется чтобы указать период времени, когда период существовал в системе. По этой линии достаточно просто отследить, в каких взаимодействиях системы существовал объект. К примеру, если объект находится в системе постоянно, то линия его жизни будет продолжаться по всей плоскости этой диаграммы, от её самой верхней точки, до самой нижней [4].

В соответствие с заданием была разработана модель диаграммы последовательностей, с которой можно ознакомиться в приложении А (Рисунок А4). На этой диаграмме последовательностей можно увидеть «актёра» - в данном случае это Пользователь, который отправляет сообщения к объектам АТС и Мини АТС, помимо этого он будет получать ответные сообщения. Там же обозначены фокусы управления объектов и линии жизни.



3. Реализация системы

3.1 Диаграмма компонентов

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

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

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

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

- Для визуализации общей структуры исходного кода программной системы;

- Спецификации исполнимого варианта программной системы;

- Обеспечения многократного использования некоторых частей программного кода;

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

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

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

3.2 Диаграмма развертывания

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

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

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

Ну и наконец - манипулирования данными и технологии доступа в рамках стандартной системы «Клиент-сервер» требуют создания и размещения чрезвычайно больших БД в разнообразных сегментах корпоративной сети. Также необходимо организовать архивирование, резервное копирование, кэширование для обеспечения максимальной производительности системы. Каждый из этих аспектов необходимо реализовать визуально - только тогда можно будет в полном объёме оценить программные и технологические особенности реализации распределённой архитектуры.

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

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

На диаграмме развёртывания присутствуют графические изображения устройств, процессоров, а также связей меж ними. Она отличается от диаграммы логического представления тем, что она является единой для всей системы, т.к. она должна полностью показывать особенности её реализации. Фактически, данная диаграмма оканчивает процесс ООАП для выбранной программной системы. Её разработка - «финальный аккорд» спецификации конкретной модели.

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

С моделью диаграммы развёртывания, разработанной по заданию курсового проекта, можно ознакомиться в приложении А (Рисунок А6). На этой диаграмме показана пара узлов, связанные между собой отношением реализации «Линия связи».



4. Практическое применение

В развитии телефонной связи в нашем стране можно выделить коммутационную технику трёх поколений:

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

- Из-за быстрого истирания контактов искателя появлялись шумы на линии, вследствие чего абоненты были «не в восторге» от качества обслуживания;

- Низкая надёжность коммутационного оборудования;

- Быстродействие тоже оставляло желать лучшего;

- Из-за моральной устарелости АТС, было крайне сложно достать необходимые запчасти;

- При эксплуатации АТС требовалось большое количество сотрудников;

- Малая проводимость линий.

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

2. Второе поколение систем коммутации было представлено автоматическими телефонными станциями координатного типа, например, это отечественные АТСК, АТСК-У, ПСК-1000, АТС 50/200 и т.д. Коммутация производится с помощью многократного координатного соединителя (МКС), устройство, которое коммутировало Х входных каналов на Y выходных. Контакты МКС управлялись с помощью электромагнитов. По сравнению с АТС ДШ, такие станции обладали некоторыми преимуществами:

- Абоненты получили более высокое качество связи;

- Для обслуживания АТС требовалось меньше людей;

- Увеличение доступности и проводности, как и использования линий;

Тем не менее, такие АТС были далеки от идеала - они очень сильно зависели от подготовки обслуживаемого персонала и возраста АТС. Всё это и привело к созданию третьего поколения АТС.

3. Речь идёт о квазиэлектронных АТС, а также электронных телефонных станциях. В этих станциях удалось избавиться от недостатков, присущим предыдущим поколениям АТС. Именно поэтому такие АТС и используются практически повсеместно. Коммутация производится под контролем «процессора», с помощью герконов.

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

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

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

При нормальном качестве модемной связи, на нормальной линии можно добиться отличного качества связи. Отдельно стоит упомянуть EWS - эта система создана практически «на все случаи жизни», с точки зрения телефонных станций, их размеров, диапазона услуг и производительности. Архитектура EWSD отвечает множеству требований из различных областей применений, её легко можно использовать в качестве АТС в небольшой деревушке, с минимальной ёмкостью, так и в качестве «массивной» транзитной станции с максимальной ёмкостью, в плотном мегаполисе.

Что же сделало EWSD столь универсальной? Прежде всего это структура аппаратных средств и ПО, которое ориентирована на выполнение конкретных функций, а также её модульность. Благодаря распределенным процессором и локальному управлению оных, получилось создать необычайно «гибкую» станцию.

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

EWSD имеет широкий и ориентированный на будущее спектр применения, и может использоваться как:

- Транзитная АТС;

- Местная АТС;

- В качестве концентратора;

- Сельской АТС;

- Международной АТС;

- Коммутационного центра для подвижных объектов;

- Узла коммутации в качестве части интеллектуальной сети;

- Коммутационного центра цифровой сети интегрального обслуживания;

- Коммутаторной системы;

- И так далее.



Заключение

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

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

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



Литература

1. А.П. Пашкевич, О.А. Чумаков. Современные технологии программирования. Конспект лекций - БГУИР, 2007 - 64 с.

2. Грейди Буч, Айвар Джекобсон, Джеймс Рамбо. Язык UML. Руководство пользователя. - СПб.:Питер, 2009. - 459с.

3. Новиков Ф.А., Иванов Д.Ю. Моделирование на UML. Теория, практика, видеокурс. ? СПб.: Профессиональная литература, Наука и Техника, 2010

4. Буч Г. Введение в UML от создателей языка. - Спб: Питер, 2015



Приложение

(обязательное)

Диаграмма классов

Диаграмма прецедентов



Диаграмма состояний

Диаграмма последовательностей

Диаграмма компонентов



Диаграмма развертывания

Размещено на Allbest.ru

...