3. Описание архитектуры системы StarUML 16

4. Исследование технологий моделирования процессов и бизнес моделирования. 19

Обоснование выбора объектно-ориентированного подхода для реализации модуля. 48

1.Разработка алгоритма решения задачи в системе StarUML. 50

2.Кодирование с использованием среды разработки Net Beans и языка программирования JavaScript. 52

3.Отладка программы. 57

Состав группы разработчиков 60

Календарный план работ 61

1. Охрана труда на рабочем месте программиста. 74

1.1 Описание рабочего места программиста 74

1.2 Освещенность рабочего места 79

1.3 Параметры микроклимата на рабочем месте. 80

1.4 Нормирование шума. 82

1.5 Вентиляция 83

I. Специальная часть работы Введение

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

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

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

1. Исследование предметной области моделирования процессов.

UML как инструмент моделирования.

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

• Статическая структура – описывает, какие типы объектов важны для моделирования системы и как они взаимосвязаны.

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

Эти два аспекта модели UML идут рука об руку, и ни один из них не является по настоящему полным без другого.

Класс UML и его структура соответствуют типу сущности и его структуре на ER-диаграмме. В UML:

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

• Атрибут - Поименованный участок внутри классификатора (интерфейса, типа, класса, подсистемы, БД или компонента), описывающий интервал значений, которые могут содержать экземпляры классификатора.

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

• Метод: - Реализация операции. Он определяет алгоритм или процедуру, которая создает результаты операции.

• Отношение: - Семантическая связь между элементами модели. Примеры отношений включают ассоциации и генерализации.

• Ассоциация: - Семантическое отношение между двумя или более классификаторами, которое включает связи между их сущностями.

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

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

Классификатор — фундаментальная концепция в UML. Это абстрактный класс UML, включающий различные подклассы нотаций UML, которые можно использовать для классификации объектов по структуре и поведению. Классы, типы, интерфейсы, подсистемы, компоненты и БД — это все виды классификаторов. Часто нотации диаграмм UML применяются к классификаторам в целом, а не просто к классам. Термины объединяются, образуя семантику класса на диаграмме класса UML, т. е. чтобы придать смысл, нужно создать диаграмму класса с нотацией, соответствующей этим концепциям, так, как их определяет UML. Диаграмма класса — это структурная или статическая диаграмма, с помощью которой осуществляется моделирование структуры системы классов. Во многом диаграммы классов сильно напоминают ER-диаграммы. Если сравнить определение класса, данное выше, с определением типа сущности для ER-диаграммы, можно увидеть, что они в основном одинаковы. Различия состоят в моделировании операций и отношений.

Большинство поддерживающих UML инструментов позволяют организовать классы независимо от структуры диаграммы UML, как предлагает спецификация UML, т. е. можно моделировать все классы в одной диаграмме, а можно разбить их на части в нескольких диаграммах. Некоторые инструменты допускают обе возможности, позволяя определить классы в репозитории или на отдельной диаграмме, из которой создаются другие диаграммы, ссылающиеся на репозиторий в отношении класса и структуры отношении. Таким образом, можно показать различные точки зрения па систему без дублирования действительных усилий по моделированию. Во многом организация диаграмм зависит от инструментов, используемых для их изображения. С помощью простых изобразительных средств можно организовать классы как угодно, но для этого потребуется много работы. Используя развитые инструменты, например Rational Rose, StarUML, можно позволить такому средству сделать большую часть работы.

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

Пакет UML — это группировка элементов модели. Подсистема UMI. — это разновидность пакета, представляющая спецификацию и реализацию набора поведений, что близко к концепции кластера автора. Подсистема — это также вид классификатора, и можно ссылаться на нее в любом месте, где допустимо использовать класс или интерфейс. Спецификация состоит из набора вариантов использования и их отношений, операций и интерфейсов. Реализация — это набор классов и других подсистем, которые обеспечивают определенное в спецификации поведение. Спецификация и реализация связываются через набор взаимодействий, отображений между вариантами использования или интерфейсами. Эти подсистемы являются строительными блоками или компонентами, образующими систему ПО. Обычно подсистемы группируют несколько классов вместе, хотя могут быть подсистемы с одним классом или даже подсистемы, которые образуют только внешний вид для других подсистем, совсем без классов, имея только интерфейсы. Подсистемы часто соответствуют библиотекам со статическими (LIB) или динамическими связями (DLL), представляющими внешние интерфейсы подсистемы для повторного использования другими библиотеками. Пакеты в действительности представляют собой пространства имен, поименованные объединения элементов, имеющие уникальные имена внутри группы. Подсистемы гораздо более важны и образуют основу для разработки системы. Можно использовать пакеты как таковые для создания легковесных групп внутри подсистем без необходимости разработки отдельных вариантов использования и взаимодействия.

Модель UML — это пакет, содержащий полное представление системы с данной точки зрения на моделирование. Можно иметь различные модели системы, используя различные точки зрения или уровни. Например, можно иметь модель анализа, состоящую исключительно из вариантов использования, и модель разработки, состоящую из подсистем или классов. Кроме моделей и подсистем имеется несколько видов пакетов,

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

.

• Система - пакет, содержащий все модели системы.

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

• Скелет - пакет, представляющий собой расширяемый шаблон для использования в определенном домене, состоящий в основном из образцов.

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

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

Концепция системной архитектуры как связанных и вложенных пакетов помогает структурировать систему для оптимизации возможности повторного использования. Целью помещения элементов модели в пакеты является разъединение больших частей системы. Это в свою очередь позволяет инкапсулировать крупные части системы в пакеты, которые становятся компонентами повторного использования. Другими словами, пакеты — основа для создания компонентов повторного использования, а не класса. Пакеты обычно имеют интерфейс пакета или набор интерфейсов, моделирующий службы, которые предоставляет пакет. Другие пакеты получают доступ к элементам пакета через эти интерфейсы, но они ничего не знают о внутренней структуре пакета. Необходимо представлять системную архитектуру как набор пакетов и их интерфейсов, а не как коллекцию связанных между собой сущностей БД. Необходимо рассматривать различные схемы подсистем и, следовательно, различные БД, даже если на самом деле они создаются вместе в одной физической схеме. Сами БД становятся пакетами на некотором уровне, представляя общие данные, когда происходит детализация действительной структуры реализации системы. Разбиение системы на несколько БД дает возможность модуляризации системы для повторного использования. Можно создать пакет Человек, позволяющий моделировать людей и относящиеся к ним объекты (адреса, например). Можно встраивать этот пакет в несколько систем, повторно используя схему БД, вложенную в него вместе со всем прочим. Можно даже повторно задействовать реализацию БД, которая в конце концов является целью трехзвенной архитектуры ANSI/SPARC. В основе большинства пакетов лежат два основных организующих принципа. Минимизация такого взаимодействия дает четкое представление о том, включать ли класс в тот или иной пакет. С точки зрения БД нужно рассмотреть другой аспект: транзакции. Минимизация количества пакетов, являющихся частью транзакции,— обычно замечательный способ. Идеально иметь транзакции в пределах одного пакета.

По мере этого также следует обращать внимание на структуру транзакций. Часто можно упростить структуру пакетов, понять, как сценарии вариантов использования влияют на объекты в БД. Начните создавать подсистемы путем группировки вариантов использования, которые влияют на подобные объекты сообща. Можно также обнаружить интересные способы модификации вариантов использования для упрощения транзакций. Если есть способ вновь определить требования для минимизации числа пакетов, то в итоге получится лучшая система. Поскольку варианты использования соответствуют транзакциям, этот метод гарантирует, что транзакции окажутся внутри пакетов, а не будут распространяться на всю систему.

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

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

Символ класса — прямоугольник, содержащий до трех разделов, как показано на Рис 1. Верхний раздел содержит имя класса и свойства, если они есть; средний раздел — список атрибутов и их свойства; нижний — список операций и их свойства. Можно спрятать или вывести на экран столько деталей, сколько нужно. Обычно прячут большинство деталей при импорте класса в другую диаграмму, показывая ее только как ссылку. Можно также сделать это для ясности при выводе на экран диаграммы классов как верхнего уровня модели классов, поскольку списки используются в больших подсистемах достаточно широко.

Рис.1 Символ класса

Имя класса является уникальным в пакете, представляющем собой пространство имен, область действия имен элементов пакета. Можно иметь классы с одним и тем же именем в разных пакетах. Чтобы обратиться к объекту в другом пакете, к имени объекта добавляют префикс в виде имени пакета в формате "пакет::класс". Символ :: — это операция разрешения контекста, присоединяющая имя пространства имен к классу. Можно вкладывать пространства имени, чтобы таким образом иметь несколько префиксов для имени класса; пакет1;:пакет1.1::пакет1.1.3::класс, например, означает, что пакет1,1.3 определяет класс в пакете пакета 1.1, который, в свою очередь, вкладывается в пакет пакета.

Верхний раздел символа класса на диаграмме содержит больше, чем просто имя класса. Классы, которые планируется сделать устойчивыми, имеют стереотип, указывающий на это: "устойчивый". Стереотип устойчивости говорит о том, что система не разрушает состояние сущности при разрушении сущности. "Устойчивый" класс преобразуется позже в нижележащую реализацию (например, реляционную таблицу, объектно - реляционный тип или объектно - ориентированный устойчивый класс). Абстрактный класс — это класс, не имеющий экземпляров. Он существует прежде всего для представления общей абстракции, которую используют несколько подклассов. UML предлагает, чтобы символ класса показывал абстракцию с помощью выделения имени класса курсивом. Можно также выдать на экран свойство под именем класса в фигурных скобках: [абстрактный]. Превращение устойчивого класса в абстрактный не имеет отношения к данным в реляционной или объектно-реляционной БД, в отличие от его влияния на временные объекты и объектно-ориентированные БД. В связи со способом преобразования ОО-модели данных в схему реляционные БД действительно имеют данные для абстрактного класса. Эти данные представляют собой часть конкретных объектов, возникающих из абстрактного класса, а не экземпляр самого абстрактного класса. На Рис. 2 показан класс Человек как простой пример абстрактного устойчивого класса с различными атрибутами и операциями.

Рис. 2 Устойчивый класс Человек.

В случае на Рис. 2 показаны видимость, имя и тип - выражение. Имеются три символа для видимости, получающие свои значения из концепции квалификатора доступа C++:

+ Общедоступная видимость (public), означающая, что любой другой

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

# Защищенная видимость (protected), когда только методы класса или

общедоступного или защищенного подкласса могут непосредственно

проверить либо изменить значение атрибута.

— Скрытая видимость (private), означающая, что только методы класса

(но не наследующих классов) могут непосредственно проверить или

изменить значение атрибута.

Стандартная нотация UML не определяет каких бы то ни было стереотипов атрибутов, ограничения объектов и бизнес-правил, а предлагает некоторые расширения тегированных атрибутами значений. Начальное значение — это значение, которое система автоматически присваивает атрибуту, когда создается экземпляр класса. Оно, например, непосредственно преобразуется в значение DEFAULT в операторе SQL CREATE TABLE. Абстрактный устойчивый класс Человек на Рис. 2 имеет несколько защищенных атрибутов и несколько общедоступных. Во время следующего цикла разработки можно будет добавить еще общедоступные операции (для получения и задания различных атрибутов), если потребуется.

Можно, в частности, добавить конструктор, предоставляющий большинство данных при создании экземпляра объекта плюс ряд операций для предоставления доступа к значениям, плюс несколько операций для задания таких значений, как ДатаСмерти, которая может измениться по время жизненного цикла объекта Человек. Можно принять некоторые упрощающие соглашения для получения и задания атрибутов. Если атрибут делают общедоступным, стандарты реализации могут преобразовать это в защищенную структуру данных имеете с операциями получения и задания. Можно добавить к атрибуту значение, помеченное только на чтение, чтобы определить создание только операций получения данных. Это именно та схема, которую использует, например. CORBA IDL для генерации классов.

Выражение типа данных зависит от языка. При определении устойчивых классов обычно используются типы данных SQL-92 или ODMG-2 ODL. Это позволяет делать стандартный SQL или ODL, в то же время предоставляя достаточно данных для создания объявлений на других языках программирования. Как SQL-92, так и ODL имеют языковые привязки, преобразующие типы данных SQL/ODL в типы данных языков программирования. К сожалению, стандарт SQL-92 не имеет никаких привязок к языкам ООП, но можно для этого добавить стандартные привязки к стандартам разработки. Можно также определить типы данных C++, Java или других языков, а затем осуществить преобразование в типы SQL. ODL имеет стандартные привязки для этих языков.

UML уравнивает атрибуты и ассоциации: тип данных атрибута — это имя класса или типа, показывающий, таким образом, ассоциацию к этому классу или типу. В общем случае ООП рекомендуется определять атрибуты только для примитивных типов данных языков (например, INTEGER, VARRAY (FLOAT) или char[1000]). Для представления объектов, являющихся экземплярами классов, следует всегда пользоваться ассоциациями. Позвольте CASE-средствам или алгоритмам преобразования выполнить работу по созданию подходящих атрибутов в таблицах, типах объектов или объявлениях классов. Для специального случая разработки устойчивого класса необходимо определить атрибуты, преобразующиеся в стандартные примитивные типы данных целевой DBMS. Все типы являются стандартом SQL, кроме Пола и СемейногоПоложения. Это простые типы перечисления, действующие в некотором диапазоне кодированных значений (например, 'М' и 'Ж' для Пола и 'Холост' и 'Женат' для СемейногоПоложения). Большинство продуктов DBMS имеют некоторые способы непосредственного представления этих типов, хотя и не все. Если нет уверенности относительно типа, нужно сделать его классом и ассоциацией, а не атрибутом.

Атрибуты с областью действия класса имеют единственное значение для всех объектов класса, т. е. все объекты используют одно и то же значение и все видят любое изменение этого значения. Реляционные таблицы не имеют атрибутов с областью действия класса, а ОР и ОО-типы часто имеют такие атрибуты. В C++ атрибут с областью действия класса становится переменной статического класса памяти. Обычное использование этого в классах фабрики домена состоит в представлении статического оператора SQL, с помощью которого фабрика запрашивает коллекцию объектов. Это имеет меньше приложений в самих устойчивых классах. Атрибуты устойчивых классов имеют ряд требований помимо стандартных свойств UML. В частности, нужно иметь возможность определения null, ключей, уникальности и ограничений домена. Последующий раздел "Объектные ограничения и бизнес-правила" рассматривает специальные свойства UML, соответствующие этим ограничениям, такие как OID, альтернативный OID и со свойством null. В самом нижнем разделе прямоугольника класса содержатся операции. Можно определить операции с возвращаемыми типами данных, как на Рис. 2. Предоставляя информацию о классах и атрибутах, нотация класса позволяет определить почти полную модель данных. Расширение классов поведением через операции, методы и интерфейсы дает еще больше возможностей для спецификации проекта БД. Однако диаграмма классов становится гораздо более интересной, когда классы начинают соотноситься друг с другом при помощи отношений генерализации и ассоциации.