Обоснование выбора метода, технологии и средства проектирования программного обеспечения
Для выполнения данной курсовой работы был выбран объектно-ориентированный подход к проектированию. С помощью ООП подхода можно упростить задачу внесения изменений в системную архитектуру.
Мною был выбран язык UML унифицированный графический язык моделирования для описания, визуализации, проектирования и документирования ОО систем. UML призван поддерживать процесс моделирования ПС на основе ОО подхода, организовывать взаимосвязь концептуальных и программных понятий, отражать проблемы масштабирования сложных систем. Модели на UML используются на всех этапах жизненного цикла ПС, начиная с бизнес-анализа и заканчивая сопровождением системы. Преимущества UML
UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;
UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
UML получил широкое распространение и динамично развивается
Мною была выбрана программа Rational Rose, эта программа поддерживает язык UML, удобна в эксплуатации.. Для написания программы приложений мною была выбрана программа BorlandDelphi 7, с его помощью можно быстро осуществить написания курсовой работы.
Создание информационной системы
Этап анализа и планирования требований
На данном этапе проектирования автоматизированной информационной системы «Автобусное предприятие» определяются требования к системе, а также строится диаграмма вариантов использования.
Автоматизированная информационная система «Автобусное предприятие» должна содержать:
справочник водителей:
просмотр информации о водителях
ввод информации о водителях
редактирование информации о водителях
удаление информации о водителях
справочник автобусов
просмотр информации об автобусах
ввод информации об автобусах
изменение информации об автобусах
удаление информации об автобусах
справочник маршрутов
просмотр информации о маршрутах
ввод информации о маршрутах
изменение информации о маршрутах
удаление информации о маршрутах
документ рейс
просмотр информации о документе
ввод информации о документе
изменение информации о документе
удаление информации о документе
отчет обо всех рейсах
Диаграмма вариантов использования – диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне. Основное назначение диаграммы — описание функциональности и поведения, позволяющее заказчику,конечному пользователюиразработчикусовместно обсуждать проектируемую или существующуюсистему.
актёр («эктор») — стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующего с некоторой сущностью (системой, подсистемой, классом). Актёры не могут быть связаны друг с другом (за исключением отношений обобщения/наследования).
прецедент — эллипс с надписью, обозначающий выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам. Надпись может быть именем или описанием (с точки зрения актёров) того, «что» делает система (а не «как»). Имя прецедента связано с непрерываемым (атомарным) сценарием — конкретной последовательностью действий, иллюстрирующей поведение. В ходе сценария актёры обмениваются с системой сообщениями. Сценарий может быть приведён на диаграмме прецедентов в виде UML-комментария. С одним прецедентом может быть связано несколько различных сценариев
Существуют правила для построения диаграммы ВИ:
не моделировать связи между действующими лицами. По определению действующие лица находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции;
не соединять стрелкой два варианта использования непосредственно (диаграммы данного типа описывают только сами варианты использования, а не порядок их выполнения);
каждый вариант использования должен быть инициирован действующим лицом. Это означает, что всегда должна быть стрелка, начинающаяся на действующем лице и заканчивающаяся на варианте использования.
Диаграмма вариантов использования для автоматизированной информационной системы «Автобусное предприятие» представлена на рисунке 1.
Рисунок 1 - Диаграмма вариантов использования