Файл: Разработка модели автоматизированной системы «Аптека №73».pdf

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

Проектирование – это разработка технического проекта новой ИС. Это разработка детализированных моделей системной архитектуры и ее внутренних механизмов, построение ее скелета, определение идей, технологий, базовых сущностей, моделей данных, разработка прототипов интерфейсов пользователя и подходов к реализации требуемых функций. В проектировании создается структура объектов. Результатом работы обычно выступает технический проект.

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

Целью курсовой работы является разработка модели автоматизированной системы «Аптека №73», в которой требуется выполнить моделирование предметной области аптеки, используя язык UML, подготовить техническую документацию для разработки программного продукта (техническое задание на программное обеспечение и спецификации).

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

Задачи работы:

рассмотреть понятие и применение UML-диаграмм;
рассмотреть основные виды UML-диаграмм;
дать краткую характеристику ОАО «Аптека № 73»;
описание бизнес-процессов и спецификацию настроек ИС в ОАО «Аптека № 73» ;
составить проект реализации операций бизнес-процесса «Планирование закупок и размещение заказов поставщикам».

Объект исследования – аптечная компания ОАО «Аптека № 73».

Предмет исследования – операции бизнес-процесса «Планирование закупок и размещение заказов поставщикам»

Научно-методической основой работы служат труды отечественных и зарубежных ученых в области ИТ - инфраструктуры, теории проектирования. При выполнении работы использовалась научно-методическая литература, публикации в периодической печати и научных изданиях, материалы Интернет-порталов, информация, предоставленная ОАО «Аптека № 73».

Методы исследования – анализ информации, методы анализа информационных показателей.

Глава 1. Теоретические основы и виды диаграмм UML

1. Понятие и применение UML

UML - это специальный язык, описывающий объектно-ориентированные модели, которым в будущем суждено стать программным кодом. Расшифровывается же аббревиатура UML как Unified Modeling Language - унифицированный язык моделирования.

История этого языка началась, по компьютерным меркам, не так уж недавно, но и не сказать, чтобы сильно давно - в 1994 году. Так что UML практически ровесник нашей газеты. Зародился он в недрах компании Rational Software, которая задумала выпустить на рынок новый язык объектно-ориентированного моделирования - естественно, лучший, чем все, которые уже существовали на тот момент.

Обычно начало истории UML связывают с фамилиями Буч, Рамбо и присоединившегося к ним позже Якобсона, которые в конце 1995 уже создали консорциум Object Management Group (OMG), который осенью 1996 выпустил версию 0.9 спецификации UML, которую многие считают важной вехой в истории языка. Поскольку после неё к консорциуму присоединились компании Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, сама прародительница UML Rational Software, а также Texas Instruments и Unisys. С их помощью в январе 1997 увидела свет версия 1.0 стандарта. Но сейчас, конечно, более актуальной является выпущенная в 2005-м версия 2.0.

UML - язык формальный и искусственный. Искусственный он потому, что у него имеются авторы: Гради Буч, Ивар Якобсон и Джеймс Рамбо(в то же время, развитие UML непрерывно продолжается, что ставит его в один ряд с естественными языками). Формальным его можно назвать, поскольку имеются правила его употребления (правда, описание UML содержит и явно неформальные элементы). Еще один нюанс: UML - графический язык моделироапния общего назначения (т. е. его можно применять для проектирования чего угодно - от простых качелей, до сложного аппаратно-программного комплекса или даже космического корабля), предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых в ходе разработки.

Как и любой формальный искусственный язык, UML содержит следующие части:

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

UML – это Unified Modeling Language, как следует из названия – унифицированный язык моделирования. UML представляет собой набор соглашений, которые предназначены для облегчения процесса моделирования и обмена информацией в проектной группе. Наличие стандартизированной нотации позволяет сократить время на усвоение информации, упрощает общение и взаимодействие, облегчает документирование.

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

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

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

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

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

2.2. Виды UML- диаграммы

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

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

Диаграммы классов (class diagram), - носит структурный характер.

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

Основным элементом диаграммы классов является класс.

Обозначается значком:

Рисунок 1 – Значок диаграммы классов

Класс состоит из двух частей – заголовка с именем класса и тела с описанием его полей (Атрибуты – в терминах UML) и методов (Операции - в терминах UML).

Абстрактные классы отличаются наклонным написанием заголовка:

Рисунок 2 – Значок абстрактных классов

Под атрибутами класса в терминологии UML понимают его поля.

Атрибуты записываются с указанием доступности, имени и типа.

Например:

Рисунок 3 – Атрибуты

Знак «-» означает, что атрибут является приватным (private).

Знак «+» означает, что атрибут является публичным (public).

Знак «#» означает, что атрибут является защищенным(protected).

После имени следует указание типа атрибута.

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

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

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

Проще всего привести описание диаграммы коммуникаций на примере:

Рисунок 4 – Описание диаграммы коммуникаций

На примере видим, что актор User взаимодействует с экземпляром страницы LoginPage, который в свою очередь работает с классом SecutiryManager, который оперирует объектами типа User.

Элементы диаграммы коммуникаций могут быть связаны отношением «Ассоциация». Как я уже указывал выше Ассоциация имеем достаточно широкое значение и может трактоваться по-разному.

Диаграммы прецедентов (use case diagram), является отправной точкой в процессе моделирования. Она предназначена для описания взаимодействия проектируемой системы с любыми внешними или внутренними объектами - пользователями, другими системами и т.п.

Основными понятиями при работе с диаграммой вариантов использования являютсяАктор (Actor) и Вариант использования (Use case).

Актор – это роль, которую выполняет пользователь или другая система, при взаимодействии с проектируемой системой.

Проектирование диаграммы вариантов использования начинается с определения списка Акторов. На диаграммах Актор обозначается следующим значком:

Рисунок 5 – Значок актора

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