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

Темой курсовой работы является ООА (Объектно-ориентированный анализ), а также проектирование ПО встроенного микропроцессора в учрежденческой мини АТС (автоматической телефонной станции). Автоматическая телефонная станция используется для соединения между собой подключенных к АТС абонентов, как между собой, так и подключенных абонентов с внешней городской сетью. АТС имеет фиксированное число входящих городских линий, которое невозможно расширить, однако при необходимости его достаточно легко оптимизировать. В большинстве случаев линии не закреплены за каким-то определенным телефоном, хотя если возникнет такая необходимость - то одну из линий можно закрепить за руководителем или определенным сотрудником, в остальных случаях АТС просто подключит сотрудника к свободной линии, при ее наличии. Помимо вышеперечисленного, АТС обладает широким набором функций - вроде перевода звонка на определенного сотрудника, разговора нескольких абонентов одновременно), переключение вызывающего абонента на факс и так далее.Каждый из абонентов подключен к ней линией связи, а мини-АТС производит коммутацию линий. Сперва абонента А поднимает трубку телефона, после чего мини-АТС получает сигнал «Трубка», и в ответ посылает сигнал «Тон». После принятия этого сигнала, абонента А набирает телефонный номер, посылает три сигнала «Цифра». Если абонент Б занят - то абонент А получает сигнал «Занято». Разговор кончается, когда один из абонентов кладет трубку, в результате чего АТС получает сигнал «Конец», а второй абонент получит сигнал «Тон».Первое упоминание о UML датируется октябрем 1994 года, когда Джеймс Румбах и Гранди Буч из RSC (Rational Software Corporation) решили унифицировать методы OMT и Booch. Несмотря на высокую популярность обоих методов, работа была направлена в первую очередь на изучение всех известных объектно-ориентированных методов. Уже в октябре 1995 года был подготовлен и опубликован проект унифицированного метода, который получил название «Unified Method». Изначально, авторы OMT, OOSE и Booch планировали создать унифицированный язык моделирования исключительно для вышеперечисленных методик. Это казалось логичным, т.к. каждый метод был множество раз проверен на практике, и «показал» собственную продуктивность при решении множественных задач ООАП.В ООАП центральной место отведено разработке логической модели в качестве диаграммы классов. Аналогичная нотация используется и для экземпляров класс, с единственным различием - к имени класса добавится имя объекта, а вся надпись будет подчеркнутой. UML нотация дает массу возможностей для отображения дополнительной информации, такой как: Стереотипы, общие и частные методы, параметризированные классы, абстрактные операции и класс и детализированные интерфейсы). Также можно использовать графические изображения для ассоциаций и/или их особых свойств, вроде отношения агрегации, когда в качестве составных частей класса могут выступать иные классы Эта диаграмма отображает определенные взаимосвязи между отдельными сущностями предметной области, вроде подсистем и объектов.Для того чтобы достичь этой цели сперва создается модель в виде диаграммы вариантов использования (use case diagram), в которой будут описаны функциональные назначения системы. Говоря более простым языком - в этой модели будет описано то, что система будет «Делать» во время своей работы. Прежде всего, разработка диаграммы вариантов предназначена для: - Определения общих границ и контекста моделируемой предметной области в начале проектирования системы. Разработки первоначальной концептуальной модели системы, которая впоследствии обрастет множеством деталей в форме физических и логических моделей. Вкратце суть данной диаграммы можно описать таким образом: проектируемая система представляет в множестве сущностей (Или актеров), которые взаимодействуют с системой с использованием вариантов использования.На этой диаграмме будут отображены лишь взаимосвязи со структурным характером, которые не зависят от реакции системы на внешние события и/или времени. Но для преобладающего числа физических систем, за исключением наиболее тривиальных, статических представлений будет в корне недостаточно для того чтобы смоделировать процесс функционирования так систем, не только в целом, но и их отдельных подсистем и/или элементов. Для того чтобы смоделировать поведение на логическом уровне в UML можно использовать несколько канонических диаграмм: деятельности, состояний, кооперации и последовательности. Диаграмма состояния отличается от других тем, что она описывает процесс изменения состояний исключительно для одного класса, если несколько точнее - то для одного экземпляра конкретного класса. Эта диаграмма предназначена в первую очередь для описания всех возможных переходов и последовательности состояний, которые в совокупности будут моделировать поведение элемента модели во время его жизненного цикла.В языке UML для моделирования взаимодействия меж объектами применяются соответствующие диаграммы взаимодействия.

Содержание

Введение

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

Литература

Приложение