ПРИЛОЖЕНИЕ. Пример выполнения курсовой работы

Проектирование информационной системы «Охранная фирма» с помощью языка UML

Содержание:

Введение…………………………………………………………………………………

1. Цель разработки…………………………………………………………………

2. Описание функций ИС…………………………………………………………

· Краткая информация о аппарате проектирования……………………………

3. Язык UML, история, особенности, достоинства, недостатки...................

4. Общая структура языка UML.

CASE средство Rational Rose 2003, его возможности, достоинства, особенности использования

6. Разработка программного обеспечения информационной системы «Охранная фирма»……

· Диаграмма Use-case …………………………………………………..

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

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

· Диаграммы состояний………………………………………………..

· Диаграммы видов деятельности…………………………………….

· Диаграмма размещения…………………………………...................

· Диаграмма пакетов………………………………………………….

7. Заключение………………………………………………………………….

8. Список литературы…………………………………………………………

Приложение «Результаты автоматической генерации текстов программ» (Коды)………….

Введение.

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

Один из путей решения задачи эффективной жизнедеятельности в рамках безгранично сложного окружающего нас мира – это создание упрощенных моделей, их анализ и прогнозирование. В данном курсовом проекте мы обратимся к вопросу построению и анализу определенной информационной системы. В качестве предметной области мы рассмотрим «Охранную фирму». Первой задачей данной работы является построение соответствующих диаграмм и схем. Этот анализ будет производится с помощью специализированного программного обеспечения. IBM Rational Rose – программный пакет для создания диаграмм нотации UML(англ. Unified Modeling Language — унифицированный язык моделирования), мощный инструмент построения и анализа различных диаграмм и средств с полным набором графических средств и инструментов.

2. Описание функций Информационной системы:

1)Получение лицензии

2)Сотрудничество с заказчиками

Поиск

Составление договоров

Получение объектов

Работа на объектах

Получение средств на банковский счет

3)Сотрудничество с магазином специализированной охранной одежды

Перечисление средств магазину

Получение охранной одежды

4)Прием на работу охранников

Проверка документов

Составление договоров

Назначение на объекты

Служба охранников на объектах

Выдача заработной платы

6)Составление отчетности по фирме

Обработка проделанной работы

Составление акта проделанных работ

Составление отчета в налоговую службу

Составление отчета в ОРЛЛ

Описание аппарата проектирования.

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

Использование

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

UML дает общее соглашение между разработчиками, что такое класс, компоненты и т.д.

История

В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования, разработанные Бучем и Рамбо (Object-Modeling Technique, OMT). OMT был ориентирован на анализ, а Booch — на проектирование программных систем. В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). Осенью 1995 года к компании Rational присоединился Айвар Якобсон, автор метода Object-Oriented Software Engineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод.

На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон, выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года.

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.

Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно в июне 1999, сентябре 2001 и марте 2003 года.

Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD (англ.). Последняя версия UML 2.3 опубликована в мае 2010 года.

UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005.

3.3.Диаграммы языка UML:

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

Структурные диаграммы:

- Классов

- Компонентов

- Кооперации (UML2.0)

- Развёртывания

- Пакетов

Диаграммы поведения:

- Деятельности

- Состояний

- Вариантов использования

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

- Коммуникации (UML2.0) / Кооперации (UML1.x)

- Последовательности

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

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

2. UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

3. Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

4. Сокращение числа возможных ошибок таких как: несогласованные параметры подпрограмм, несогласованное изменение атрибутов;

5. Повторное использование. Предполагается какой-либо вариант многократного использования уже существующего проекта или его части в новом проекте;

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

7. UML получил широкое распространение и динамично развивается.

Недостатки языка UML

Несмотря на то, что UML достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:

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

2. Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.

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

4. Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.

5. Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).

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

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

CASE-средства.

Аббревиатура CASE расшифровывается как Computer Aided Software Engineering(Автоматизированная Разработка Программного Обеспечения). CASE средства подразумевают процесс разработки сложных ИС в целом: создание и сопровождение ИС, анализ, формулировка требований, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Таким образом, CASE-технологии образуют целую среду разработки ИС.

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

· методология (Method Diagrams), которая задает единый графический язык и правила работы с ним.

· графические редакторы (Graphic Editors), которые помогают рисовать диаграммы; возникли с распространением PC и GUI, так называемых «upper case технологий

· генератор: по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая low case часть CASE-технологии).

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

Разумеется, существуют свои недостатки применения технологий, значимыми являются недостатки со стороны аспектов бизнеса:

· CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

· реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

Ряд преимуществ созданной системы:

· высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

· положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;

· приемлемый уровень отдачи от инвестиций в CASE-средства.

Rational Rose - CASE-средство фирмы Rational Software Corporation - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

4. Разработка ПО информационной системы “Охранная фирма”.

4.1.Use-case диаграмма (диаграмма вариантов использования, сценариев, прецедентов). Диаграммы позволяют наглядно представить ожидаемое поведение системы. Элементы, используемые на диаграмме:

· Сценарий. (Определяет один фрагмент поведения системы, без раскрытия внутреннего содержания)

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

· Интерфейс

· Комментарий

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

Расчет оценки диаграммы.

S_diagr= ,

где S_obj-оценка элемента на диаграмме, S_link- оценка связей, Оbj- кол-во объектов на диаграмме, T_obj –количество типов объектов, T_link- количество типов связи.

S _diagram=

Рис.1 Общая USE-CASE диаграмма

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

Диаграмма классов (Class diagram) — статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:

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

Элементы:

1)Класс - множество объектов, обладающие одинаковой структурой, поведением и отношением с другими классами.

Атрибуты-параметры класса(переменные).

Операции(методы)- функции, которые может выполнить класс или которые можно выполнить относительно него.

2)Связи между классами – поведенческие сущности, взаимодействие объектов. (Зависимость, обобщение, ассоциация, агрегирование, композиция, реализация.)

Расчет оценки диаграммы.

S_diagr= ,

S_clas₌ , где Op- количество операций, Atr- количество атрибутов.