Системный анализ и анализ требований

Рамки системы

Рамки системы – граница компетенции системы. Определяют предметную область, в которой будет работать система а так же основных исполнителей, которые будут взаимодействовать с ней. Рамки АСУ «3Dprint» представлены на рисунке 1.


Рисунок 1. Рамки системы


Исполнители и задачи

Клиент – его задачей является придти в филиал фирмы “3Dprint” и заказать для себя трехмерную модель, предоставив свои личные данные.

Касса – обслужить клиента, выслушав его требования и создав для этого соответствующий заказ.

Менеджер – назначение оператора на обслуживание принтера для печати модели.

Оператор – слежение за процессом печати принтера и устранение неисправностей.

Администратор - Добавляет и удаляет пользователей. Следит за функционированием системы

Принтер – должен распечатать трехмерную модель.

Доставщик – доставить изготовленную модель по адресу.

Прецеденты

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

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

Прецедент «Составление заказа»

Клиент приходит в филиал фирмы “3Dprint” и его целью является заказ трехмерной модели. Касса в свою очередь беседует с клиентом, обговаривая условия заказа, затем берет его личные данные – ФИО, домашний адрес, который впоследствии станет адресом доставки и счет кредитной карты. После осуществления этих операций касса создает новый заказ.

Прецедент «Инициация работы системы»

Менеджер заставляет функционировать всю систему, включая ПК.

Прецедент «Назначение сотрудников»

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

Прецедент «Управление пользователями»

Системный администратор добавляет, удаляет и изменяет права доступа пользователей, зарегистрированных в системе.

Прецедент «Обеспечение безопасности системы»

Системный администратор устанавливает необходимое ПО для безопасности. В него входят: firewall, антивирусы, антитрояны и др.

Прецедент «Печать трехмерной модели»

Оператор, получив соответствующие указания от менеджера включает трехмерный принтер для печати соответствующей модели. В процессе печати он следит за отсутствием неисправностей, и исправляет их если они возникают.

Прецедент «Составление статистики»

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

Прецедент «доставка модели»

Когда модель получает статус готовности к отправке, доставщик забирает ее на складе и отвозит клиенту по указанному им адресу.

Дополнительная спецификация

Дополнительная спецификация предоставлена в приложении 3.

Словарь терминов

Кассир – Сотрудник отделения, работающий с клиентами и принимающий их заказы.

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

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

Модель предметной области

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

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

Идентификация классов понятий или концептуальных классов – составная часть исследования предметной области. Модели предметной области на языке UML строятся в форме диаграмм классов.

Исходная модель предметной области представлена на рисунке 2.


Рисунок 2. Исходная модель предметной области
В процессе разработки модели предметной области необходимо идентифицировать связи (ассоциации) между концептуальными классами, удовлетворяющие информационным требованиям разрабатываемых на текущей итерации сценариев, а также выделить те из них, которые способствуют лучшему пониманию модели предметной области.

Ассоциация – это связь между типами (или точнее, экземплярами типов), отражающая некоторое значимое и полезное отношение между ними.

В языке UML ассоциации описываются как "семантические взаимосвязи между двумя или несколькими классификаторами и их экземплярами".

Модель предметной области с ассоциациями изображена на рисунке 3.



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

Атрибут –  это абстрактное свойство объекта.

В модель предметной области включаются те атрибуты, для которых определены соответствующие требования (например, прецеденты) или для которых необходимо хранить определенную информацию.

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

Модель проектирования

Диаграмма деятельности

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

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

Диаграмма деятельностей для основного успешного сценария с возможными альтернативными потоками представлена в
приложении 2.

Диаграмма взаимодействия

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

Диаграммы взаимодействия представлены диаграммами последовательностей и кооперации.

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

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

Диаграмма последовательности для задачи «Сделать заказ» представлены на рисунке 5.


Рисунок 5. Диаграмма последовательности

Диаграмма сотрудничества (кооперации)

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

Диаграмма сотрудничества на основе основного успешного события представлена на рисунке 6.


Рисунок 6. Диаграмма сотрудничества
Описание операций:

1.                 Предоставить личные данные() – кассир, принимая очередного клиента вводит его личные данные в систему.

2.                 Ввести данные() – клиент, увидев что все введено верно, подтверждает правильность ввода и данные проходят дальше.

3.                 Отобразить() – при надобности заказ отображается на экране в виде листа А4 с возможностью распечатать.

4.                 Передать() – готовый заказ передается системе для дальнейшей работы с ним.

5.                 Заполнить() – система определяет внутренние переменные (номер модели, номер клиента в системе и тп) и заполняет соответствующие поля в заказе.

6.                 Присвоить ID() – система присваивает заказу уникальный ключ.

7.                 записать в БД() – заказ в готовом виде сохраняется в БД.

8.                 Печать() – готовый заказ с полями, заполненными внутренними переменными передается на печать и передается клиенту.

9.                 Подписать() – клиент подписывает бумажную версию договора и оставляет ее себе. Цифровая версия договора шифруется и клиент получает открытый ключ цифровой версии документа, который может скопировать себе.

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

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

Класс — абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов.

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

Кратность — спецификация области значений допустимой мощности, которой могут обладать соответствующие множества.

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

Диаграмма классов для разрабатываемой АСУ «3Dprint» представлена на рисунке 7.



Рисунок 7. Диаграмма классов

Модель данных

Так как построение моделей и реализация АСУ «3Dprint» осуществляется в программной среде CaseBerry, то для хранения данных выбрана СУБД Microsoft SQL 2000.

CaseBerry на основе диаграммы классов в автоматическом режиме генерирует структуру базы данных и создает эту базу на сервере баз дынных.

Логическая модель полученной базы данных представлена на рисунке 8.



Рисунок 8. Логическая модель данных

Модель реализации

Так как построение диаграмм осуществляется в программном комплексе CaseBerry в качестве основного языка программирования целесообразно выбрать язык программирования C#. CaseBerry оснащён функцией автоматической генерации программного кода основываясь на диаграмме классов.

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



Рисунок 9. Диаграмма представлений
С помощью диаграммы представлений можно изменять и другие параметры будущего приложения, такие как: кнопки панели инструментов, заголовки и др.

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

После сборки CaseBerry предлагает запустить приложение (рисунок 10).


Рисунок 10. Запуск приложения
После запуска приложения загружается основное окно программы (рисунок 11).



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

В приложении 4 представлен исходный код классов.

Заключение

При выполнении курсового проектирования был создан прототип автоматизированной информационной системы «трехмерная печать». В процессе проектирования были закреплены навыки составления UML диаграмм и анализа предметной области.

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

В проектировании будут задействованы средства построения UML диаграмм, средства управления разработкой, относящейся к классу Rational Unified Process (RUP), а также, возможно, и программно-ориентированная среда для проектирования и разработки CASEBERRY. Данный продукт хорошо позиционирует себя на рынке CASE-средств и отлично выполняет возложенные на него функции.