Главная страница
Навигация по странице:

  • 2.3 Проектирование программного средства

  • Программное средство Инвентаризация компьютеров. ПЗ_new. Руководство пользователя для разработанной системы. Пятый раздел приводит данные по информационной безопасности приложения


    Скачать 4.8 Mb.
    НазваниеРуководство пользователя для разработанной системы. Пятый раздел приводит данные по информационной безопасности приложения
    АнкорПрограммное средство Инвентаризация компьютеров
    Дата25.05.2023
    Размер4.8 Mb.
    Формат файлаdocx
    Имя файлаПЗ_new.docx
    ТипРуководство пользователя
    #1158409
    страница4 из 9
    1   2   3   4   5   6   7   8   9

    1.2 Выводы по разделу


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

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

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

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

    2.1 Планирование архитектуры сервиса


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

    Таким образом, приложение должно реализовывать следующие функциональные требования:

    – добавление, удаление и редактирование оборудования;

    – фильтрацию и поиск оборудования;

    ­ генерацию специальных идентификационных кодов для печати;

    – оповещение о изменении статусов оборудования.

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

    Резюмировав все требования и приняв во внимание выбранную архитектуру, получим схему, изображенную на рисунке 2.1.



    Рисунок 2.1 – Архитектура приложения

    Все взаимодействие с сервером сводится к четырём операциям (Четыре — это необходимый и достаточный минимум, в конкретной реализации типов операций может быть больше):

    • получение данных с сервера (обычно в формате JSON, или XML).

    • добавление новых данных на сервер.

    • модификация существующих данных на сервере.

    • удаление данных на сервере.

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

    2.2 Обзор и определение основных технологий и средств


    Ключевыми используемыми технологиями для разработки кроссплатформенного приложения:

    • фреймворк Flutter как основа клиентского приложения;

    • фреймворк ASP.NETCore как основа серверного приложения;

    • технология GraphQL как замена RESTful-API серверного приложения;

    • база данных PostgreSQL как основная база данных.

    2.2.1 Фреймворк Flutter


    Flutter представляет собой кросс-платформенный, высокопроизводительный фреймворк с открытым исходным кодом для создания различного рода кроссплатформенных приложений для таких платформ как: Android, iOS, веб-приложения, десктопные приложения для платформ Windows, Ubuntu Linux [1].

    Flutter не использует нативные компоненты, опять же, ни в каком виде, так что не приходится писать никаких прослоек для коммуникации с ними. Вместо этого он отрисовывает весь интерфейс самостоятельно. Кнопки, текст, медиа-элементы, фон — все это отрисовывается внутри графического движка в самом Flutter.

    Для построения UI во Flutter используется декларативный подход, вдохновленный веб-фреймворком ReactJS, на основе виджетов или компонентов. Для еще большего прироста в скорости работы интерфейса виджеты перерисовываются по необходимости — только когда в них что-то изменилось (подобно тому, как это делает Virtual DOM в мире веб-фронтенда).

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

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

    Google разработали специальный архитектурный стиль строения приложения. BloC (Business Logic Component) — это архитектурный шаблон, представленный Google. Идея заключается в том, чтобы иметь отдельные компоненты (компоненты BLoC), содержащие только бизнес-логику, которая должна легко использоваться приложениями. Архитектурный стиль представлен на рисунке 2.2.



    Рисунок 2.2 – Архитектура BLoC

    2.2.2 C#


    C# – язык программирования, сочетающий объектно-ориентированные и контекстно-ориентированные концепции. Разработан в 1998–2001 годах группой инженеров под руководством Андерсa Хейлсбергa в компании Microsoft как основной язык разработки приложений для платформы Microsoft .NET. Компилятор с C# входит в стандартную установку самой .NET, поэтому программы на нём можно создавать и компилировать даже без инструментальных средств вроде Visual Studio [10].

    C# относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет строгую статическую типизацию, поддерживает полиморфизм, перегрузку операторов, указатели на функции-члены классов, атрибуты, события, свойства, исключения, комментарии в формате XML. Переняв многое от своих предшественников – языков C++, Delphi, Modula и Smalltalk – С#, опираясь на практику их использования, исключает некоторые модели, зарекомендовавшие себя как проблематичные при разработке программных систем: так, C# не поддерживает множественное наследование классов (в отличие от C++) или вывода типов (в отличие от Haskell). С помощью языка C# можно создавать обычные приложения Windows, XML-веб-службы, распределенные компоненты, приложения «клиент-сервер», приложения баз данных и т. д.

    2.2.3 Платформа .NET


    .NET Framework – это программная платформа, выпущенная компанией Microsoft, которая подходит для разных языков программирования [11].

    .NET достаточно широко распространён в сфере разработки внутрикорпоративных программных продуктов, но в веб-разработке всё же встречается относительно редко, как и другие программные продукты корпорации Microsoft. Поэтому найти разработчиков для веб-проекта бывает достаточно непросто. Использование. NET «тянет» за собой покупку и иного ПО от корпорации Microsoft (серверной ОС, СУБД и т.п.). Технология достаточно дорогая в разработке и сопровождении: кроме затрат на покупку лицензий на необходимое ПО существенный вклад в бюджет проектов вносят высокие зарплаты разработчиков.

    ASP.NET – технология создания веб-приложений и веб-сервисов от компании Microsoft. Она является составной частью платформы Microsoft. NET и развитием более старой технологии Microsoft ASP.

    2.2.4 ASP .NET Core


    Для реализации серверной части данного предложения была выбрана платформа .NET Core [12].

    Платформа ASP.NET Core представляет технологию от компании Microsoft, предназначенную для создания различного рода веб-приложений: от небольших веб-сайтов до крупных веб-порталов и веб-сервисов.

    С одной стороны, ASP.NET Core является продолжением развития платформы ASP.NET. Но, с другой стороны, это не просто очередной релиз. Выход ASP.NET Core фактически означает революцию всей платформы, ее качественное изменение.

    Версия состоит из коллекции библиотек СoreFX и небольшой оптимизированной среды выполнения CoreCLR. .NET Core – проект с открытым исходным кодом, поэтому вы можете наблюдать за его развитием и поддерживать его на GitHub.

    Среда выполнения CoreCLR (Microsoft.CoreCLR) и библиотеки CoreFX распространяются через NuGet. Поскольку версия .NET Core представляет собой компонентизированный набор библиотек, вы можете ограничить количество API для своего приложения и использовать только нужные элементы. Кроме того, можно выполнять приложения на базе .NET Core в гораздо более ограниченных средах (например, в ASP.NET Core на Nano Server).

    Чтобы улучшить компонентизацию, в .NET Core был обновлен факторинг API. Иными словами, существующие библиотеки для .NET Framework придется перекомпилировать для выполнения в .NET Core. Экосистема .NET Core является относительно новой, но она быстро развивается благодаря поддержке популярных пакетов .NET (JSON.NET, AutoFac, xUnit.net и многие другие).

    Серверные приложения с поддержкой .NET можно разрабатывать в двух поддерживаемых реализациях: .NET Framework и .NET 5 (включая .NET Core). В них используется множество одинаковых компонентов, а код можно использовать как в одной среде, так и в другой. Но между этими двумя средами также существуют и фундаментальные различия.

    ASP.NET Core может работать поверх кроссплатформенной среды .NET Core, которая может быть развернута на основных популярных операционных системах: Windows, Mac OS, Linux. И таким образом, с помощью ASP.NET Core мы можем создавать кроссплатформенные приложения. И хотя Windows в качестве среды для разработки и развертывания приложения до сих пор превалирует, но теперь уже мы не ограничены только этой операционной системой. То есть мы можем запускать веб-приложения не только на ОС Windows, но и на Linux и Mac OS. А для развертывания веб-приложения можно использовать традиционный IIS, либо кроссплатформенный веб-сервер Kestrel.

    2.2.5 Entity Framework


    Entity Framework является продолжением технологии Microsoft ActiveX Data и предоставляет возможность работы с базами данных через объектно-ориентированный код C#. Этот подход предоставляет ряд существенных преимуществ: вам не нужно беспокоиться о коде доступа к данным, вам не нужно знать деталей работы СУБД PostgreSQL и синтаксиса языка запросов T-SQL, вместо этого вы работаете с таблицами базы данных как с классами C#, с полями этих таблиц – как со свойствами классов, а синтаксис SQL-запросов, который в ADO.NET раньше нужно было вставлять в код C# в виде команд, заменен на более удобный подход с LINQ. Entity Framework берет на себя обязанности по преобразованию кода C# в SQL-инструкции [15].

    Центральной концепцией Entity Framework является понятие сущности или entity. Сущность представляет набор данных, ассоциированных с определенным объектом. Поэтому данная технология предполагает работу не с таблицами, а с объектами и их наборами.

    Любая сущность, как и любой объект из реального мира, обладает рядом свойств. Например, если сущность описывает человека, то мы можем выделить такие свойства, как имя, фамилия, рост, возраст, вес. Свойства необязательно представляют простые данные типа int, но и могут представлять более комплексные структуры данных. И у каждой сущности может быть одно или несколько свойств, которые будут отличать эту сущность от других и будут уникально определять эту сущность. Подобные свойства называют ключами.

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

    Отличительной чертой Entity Framework является использование запросов LINQ для выборки данных из БД. С помощью LINQ мы можем не только извлекать определенные строки, хранящие объекты, из бд, но и получать объекты, связанные различными ассоциативными связями.

    Другим ключевым понятием является Entity Data Model. Эта модель сопоставляет классы сущностей с реальными таблицами в БД.

    Entity Data Model состоит из трех уровней: концептуального, уровень хранилища и уровень сопоставления (маппинга).

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

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

    Уровень сопоставления (маппинга) служит посредником между предыдущими двумя, определяя сопоставление между свойствами класса сущности и столбцами таблиц.

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

    Entity Framework предполагает три возможных способа взаимодействия с базой данных:

    – Database first: Entity Framework создает набор классов, которые отражают модель конкретной базы данных;

    – Model first: сначала разработчик создает модель базы данных, по которой затем Entity Framework создает реальную базу данных на сервере;

    – Code first: разработчик создает класс модели данных, которые будут храниться в бд, а затем Entity Framework по этой модели генерирует базу данных и ее таблицы.

    2.2.6 База данных PostgreSQL


    PostgreSQL — свободная объектно-реляционная система управления базами данных (СУБД).

    Существует в реализациях для множества UNIX-подобных платформ, включая AIX, различные BSD-системы, HP-UX, IRIX, Linux, macOS, Solaris/OpenSolaris, Tru64, QNX, а также для Microsoft Windows.

    Основные преимущества PostgreSQL:

    ­ высокопроизводительные и надёжные механизмы транзакций и репликации;

    ­ расширяемая система встроенных языков программирования: в стандартной поставке поддерживаются PL/pgSQL, PL/Perl, PL/Python и PL/Tcl; дополнительно можно использовать PL/Java, PL/PHP, PL/Py, PL/R, PL/Ruby, PL/Scheme, PL/sh и PL/V8, а также имеется поддержка загрузки модулей расширения на языке C[10];

    ­ наследование;

    ­ возможность индексирования геометрических (в частности, географических) объектов и наличие базирующегося на ней расширения PostGIS;

    ­ встроенная поддержка слабоструктурированных данных в формате JSON с возможностью их индексации;

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

    2.2.7 Язык SQL


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

    SQL основывается на реляционной алгебре. Язык SQL делится на три части:

    • операторы определения данных;

    • операторы манипуляции данными (Insert, Select, Update, Delete);

    • операторы определения доступа к данным.

    Основные функции системы управления базами данных:

    • управление данными во внешней памяти (на различных носителях);

    • управление данными в оперативной памяти;

    • журналирование изменений и восстановление базы данных после сбоев;

    • поддержка языков БД (язык определения данных, язык манипулирования данными, язык определения доступа к данным).

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

    • создание в базе данных новой таблицы;

    • добавление в таблицу новых записей;

    • изменение записей;

    • удаление записей;

    • выборка записей из одной или нескольких таблиц (в соответствии с заданным условием);

    • изменение структур таблиц.

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

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

    Преимущества:

    • независимость от конкретной СУБД (несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую);

    • наличие стандартов (наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует «стабилизации» языка);

    • декларативность (с помощью SQL программист описывает только то, какие данные нужно извлечь или модифицировать. То, каким образом это сделать, решает СУБД непосредственно при обработке SQL-запроса).

    Недостатки:

    • сложность. Хотя SQL и задумывался как средство работы конечного пользователя, в конце концов он стал настолько сложным, что превратился в инструмент программиста;

    • отступления от стандартов. Многие разработчики СУБД вносят изменения в язык SQL, применяемый в разрабатываемой СУБД, тем самым отступая от стандарта. Таким образом появляются специфичные для каждой конкретной СУБД диалекты языка SQL;

    • сложность работы с иерархическими структурами.



    2.2.8 Github


    GitHub является сервисом для хостинга репозиториев Git, однако ко всему этому он включает в себя много дополнительной функциональности для осуществления контроля версий проекта. Архитектура работы Git указана на рисунке 2.3. Хотя Git – это инструмент командной строки, GitHub предоставляет графический интерфейс на основе Web. Он также обеспечивает контроль доступа и функций для совместной работы.



    Рисунок 2.3 – Архитектура работы Git

    Главной функциональной особенностью GitHub является forking – копирование репозитория из одной учетной записи пользователя в другую. Это позволяет скопировать проект, к которому у пользователя нет доступа для записи и изменения, в собственную учетную запись пользователя для последующего внесения изменений. Если пользователь вносит изменения, которые он хочет внедрить в изначальный проект, есть возможность отправить уведомление, названное pull-request первоначальному владельцу. Затем этот пользователь в первоначальном репозитории может одним щелчком кнопки объединить изменения.

    Три основные функции – fork, pull request и merge делают GitHub настолько мощным инструментом. Также GitHub имеет эффект социальной сети. Когда пользователь отправляет pull request, автор проекта может видеть его профиль, который включает все его вклады в GitHub репозитории. Если патч принят, эта информация появляется и в исходном проекте, и в профиле пользователя. Таким образом профиль пользователя схож с резюме, которое помогает разработчикам определить репутацию пользователя. Чем больше людей и проектов на GitHub, тем вероятнее разработчик проекта может получить потенциальных вкладчиков. Также есть возможность публичного обсуждения создаваемых патчей.

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

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

    2.2.9 GraphQL


    GraphQL – спецификация и язык структурирования запросов API, созданный Facebook.

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

    На первом этапе разработки кроссплатформенного приложения необходимо установить программное обеспечение.

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

    Разработка программно-технического комплекса позволит облегчить работу технического подразделения вести учёт и контроль за наличием техники на складе, её своевременной установкой, снятием, заменой и перемещением на основании заявок, полученных от различных подразделений ГУ «Казахская опорная средняя школа-интернат».

    Программно-технический комплекс должен включать в себя:

    разработанную БД, которая будет содержать информацию о подразделениях, должностях, работниках, технических средствах, видах работ, заявках и их выполнении;

     приложение пользователя, с помощью которого можно будет: дополнять данными БД, изменять их  и удалять из БД; осуществлять выборку наборов данных для отображения в формах ввода информации; осуществлять поиск данных по заданному критерию поиска; формировать отчётные формы для просмотра и печати;

    справочную систему для работы с программным обеспечением.

    Диаграмма вариантов использования (Use case diagram) или диаграмма прецедентов играет основную роль в моделировании поведения системы, подсистемы или класса. Каждая такая диаграмма показывает множество прецедентов, актеров и отношения между ними.

    Диаграмма вариантов использования или прецедентов для информационной системы учёта техники включает в себя следующее: 2 актера, 8 прецедентов, 2 отношения ассоциации, 6 cтереотипов «include» (включение), 2 cтереотип «extends» (расширение), 2 кардинальности связей.

    Диаграмма вариантов использования ИС «Учёт технических средств» представлена в соответствии с рисунком 2.4.


    Рисунок 2.4. – Диаграмма вариантов использования

     

    Администратор – актер,  выполняющий роль программиста ГУ «Казахская опорная средняя школа-интернат». Прецеденты «Администратор»:

    -«Редактирование БД» – прецедент позволяющий программисту данного предприятия редактировать БД и модифицировать ее по мере надобности;

    - «Создание триггеров и хранимых процедур» – прецедент, отвечающий за разработку триггеров и хранимых процедур программистом отдела ИС;

    - «Редактирование запросов» – прецедент, отвечающий за постоянное редактирование запросов в БД, которые создает программист;

    - «Создание фильтров» – прецедент, отвечающий за создание фильтров к БД программистом.

    «Пользователь» – актер,  выполняющий роль специалиста технического подразделения. Прецеденты «Пользователь»:

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

    - «Работа со справочной информацией» – прецедент, отвечающий за, добавление, редактирования и просмотра информации о сотрудниках, должностях, отделах, технических средств и выполняемых работ.

    -  «Формирование отчетов» – прецедент, отвечающий за печать различныхотчетов специалистом технического отдела;

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

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

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

    В группу «Учет ТМЦ» входят следующие информационные процессы:

      • приобретение ТМЦ;

      • внутреннее перемещение ТМЦ из подразделения в подразделение;

      • списание ТМЦ;

      • инвентаризация.

    Моделирование вариантов использования информационной системы бухгалтерского учета (ИСБУ) для бюджетных организаций при реализации вышеперечисленных ИП мы осуществили с помощью диаграммы прецедентов. Фрагмент этой диаграммы, отражающий прецеденты для ИП приобретения ТМЦ (по безналичному расчету) представлен на рис.1.

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

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

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

    Для составления словаря ИСБУ мы использовали классы. Для этого мы идентифицировали, в моделируемых информационных процессах сущности, важные для реализации этих процессов. На рисунке 2.5 приведен фрагмент диаграммы классов для ИП «Приобретение ТМЦ».



    Рисунок 2.5. – Диаграмма классов
    Для представления взаимодействий между классами нами было использовано три типа отношений ¾ отношения ассоциации, агрегации и обобщения. Для ассоциаций указано имя, направление имени и кратность отношения. Ассоциация «Оплата» является 5-арной, остальные ассоциации ¾ бинарные. Отношения агрегации мы использовали для моделирования взаимосвязей между классами «Бухгалтерская операция» и «Бухгалтерская проводка», а также «Организация» и «Структурное подразделение». Отношения обобщения были использованы для представления взаимосвязей между классом «Сопроводительный документ на товар» и классами «Счет-фактура», «Накладная».

    Диаграмма деятельности, отражающая ИП приобретения ТМЦ, приведена на рисунке 2.6



    Рисунок 2.6 – Диаграмма деятельности для ИП «Приобретение ТМЦ»
    Применительно к информационным процессам желательно выполнение каждого действия ассоциировать с конкретным подразделением организации. В этом случае подразделение несет ответственность за реализацию отдельных действий, а сам процесс представляется в виде переходов действий от одного подразделения к другому. Для моделирования этих особенностей нами были использованы специальные конструкции языка UML – дорожки. Название подразделения явно указывается в верхней части дорожки. Группа состояний на дорожке выполняется этим подразделением организации. В таком варианте диаграмма деятельности заключает в себе не только информацию о последовательности выполнения рабочих действий процесса, но и о том, какое из подразделений организации должно выполнять то или иное действие.

    Моделирование динамических аспектов поведения осуществлено с помощью диаграмм деятельности и последовательности.

    Информационный аспект и динамику коммуникации объектов во времени отражают диаграммы последовательностей. Мы использовали диаграммы этого типа для описания поведения в рамках вариантов использования ИСБУ (прецедентов).



    Рисунок 2.7 – Диаграмма последовательностей для прецедента «Оформить поступление ТМЦ на склад»
    На рисунке 2.8 представлена диаграмма последовательностей для прецедента «Оформить поступление на склад ТМЦ», а на рис. 5 ¾ «Оформить выдачу ТМЦ со склада».



    Рисунок 2.8 – Диаграмма последовательностей для прецедента
    «Оформить выдачу ТМЦ со склада»
    Спецификацию взаимодействий и указание потоков информации, которыми обмениваются объекты, мы осуществили с помощью конструкций языка UML сообщения. Каждое сообщение ассоциируется с некоторым действием, которое должно быть выполнено принявшим его объектом. Все сообщения упорядочены на диаграмме последовательностей по времени возникновения в моделируемом процессе.

    Стереотип сообщения create S использован для отражения действий актеров по созданию новых объектов в моделируемом процессе – бухгалтерских документов и хозяйственных операций. С помощью фокусов управления на линиях жизни отражены периоды активности и пассивности (ожидания) объектов.
    1   2   3   4   5   6   7   8   9


    написать администратору сайта