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