Учебная работа. Реферат: Проектирование КС Школа

Учебная работа. Реферат: Проектирование КС Школа

Оглавление

Введение. 2

1. Теоретические сведения о языке UML.. 3

1.1 Общие сведения. 3

1.2 Диаграммы.. 3

1.3 Достоинства UML. 3

1.4 Критика. 3

2. Проектирование информационной системы «Школа». 3

2.1 Создание диаграммы вариантов использования. 3

2.2 Создание диаграммы последовательности. 3

2.3 Создание Кооперативной диаграммы.. 3

2.4 Диаграмма Состояний для класса Заявка. 3

Заключение. 3

Перечень применяемой литературы.. 3

Введение

Целью данного курсового проекта является проектирование информационной системы «Школа». Для выполнения модели информационной системы нужна программка IBM Rational Rose, которая дозволяет создавать проекты на языке UML.

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

1. Теоретические сведения о языке UML

1.1 Общие сведения

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

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

UML дозволяет также разрабам программного обеспечения добиться соглашения в графических обозначениях для представления общих понятий (таковых как класс, компонент, обобщение (generalization), объединение (aggregation) и компании 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.

1.2 Диаграммы

В UML употребляются последующие виды диаграмм (для исключения неоднозначности приведены также обозначения на британском языке):

Structure Diagrams:

• Class diagram
• Component diagram
• Composite structure diagram
Collaboration (UML2.0)
• Deployment diagram
• Object diagram
• Package diagram
• Profile diagram (UML2.2)

Behavior Diagrams:

• Activity diagram
• State Machine diagram
• Use case diagram
• Interaction Diagrams:
• Communication diagram (UML2.0) / Collaboration (UML1.x)
• Interaction overview diagram (UML2.0)
• Sequence diagram
• Timing diagram (UML2.0)

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

• Диаграмма классов
• Диаграмма компонент
• Композитной/составной структуры
Диаграмма кооперации (UML2.0)
• Диаграмма развёртывания
• Диаграмма объектов
• Диаграмма пакетов
• Диаграмма профилей (UML2.2)

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

• Диаграмма деятель
• Диаграмма состояний
• Диаграмма прецедентов
• Диаграммы взаимодействия:
• Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
• Диаграмма обзора взаимодействия (UML2.0)
• Диаграмма последовательности
• Диаграмма синхронизации (UML2.0)

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

Есть различные точки зрения на построение диаграмм классов зависимо от целей их внедрения:

— мировозренческая точка зрения — диаграмма классов обрисовывает модель предметной области, в ней находятся лишь классы прикладных объектов;

— точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

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

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

Диаграмма композитной/составной структуры
(Composite structure diagram) — статическая структурная диаграмма, показывает внутреннюю структуру классов и, по способности, взаимодействие частей (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые демонстрируют роли и взаимодействие классов в рамках кооперации. Кооперации комфортны при моделировании шаблонов проектирования.

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

Диаграмма развёртывания
(Deployment diagram) — служит для моделирования работающих узлов (аппаратных средств, англ. node) и реликвий, развёрнутых на их. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались составляющие. Меж артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

Диаграмма объектов
(Object diagram) — показывает полный либо частичный снимок моделируемой системы в данный момент времени. На диаграмме объектов показываются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей меж объектами.

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

Диаграмма деятельности
(Activity diagram) — диаграмма, на которой показано разложение некой деятель на её составные части. Под Деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного поочередного и параллельного выполнения подчинённых частей — вложенных видов деятель и отдельных действий (англ. action), соединённых меж собой потоками, которые идут от выходов 1-го узла ко входам другого.

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

Аналогом диаграмм деятель являются схемы алгоритмов по ГОСТ 19.701-90.

Диаграмма автомата
(State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с ординарными состояниями, переходами и композитными состояниями.

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

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

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

(Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия меж частями композитной структуры либо ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации очевидно указываются дела меж элементами (объектами), а время как отдельное измерение не употребляется (используются порядковые номера вызовов).

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

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

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

Диаграмма обзора взаимодействия
(Interaction overview diagram) — разновидность диаграммы деятель, включающая фрагменты диаграммы последовательности и конструкции потока управления.

Этот тип диаграмм содержит в себе диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы разрешают с различных точек зрения разглядеть взаимодействие объектов в создаваемой системе.

Диаграмма синхронизации
(Timing diagram) — другое конфигурации состояния на полосы жизни с данной шкалой времени. Быть может полезна в приложениях настоящего времени.

1.3 Достоинства UML

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

— UML дозволяет обрисовать систему фактически со всех вероятных точек зрения и различные нюансы поведения системы;

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

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

— UML получил обширное распространение и оживленно развивается.

1.4 Критика

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

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

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

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

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

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

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

2. Проектирование информационной системы «Школа»


2.1 Создание диаграммы вариантов использования

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

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

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

2.2 Создание диаграммы последовательности

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

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

2.3 Создание Кооперативной диаграммы

В данном разделе я так же раскрыл вариант «Определение свойства познаний» при помощи кооперативной диаграммы. Данная диаграмма также как и диаграмма последовательности отражает процесс проверки свойства познаний.

Рис.3
Кооперативная диаграмма

2.4 Диаграмма Состояний для класса Заявка

Рис.4
Диаграмма Состояний для класса

Заключение

Перед мной была поставлена задачке –спроектировать схему действий работы школы. При решении задачки я воспользовался специальной программкой для проектирования RationalRoseEnterprise, сам проект выполнен на языке UML. В выполненном проекте были разработаны диаграммы логического представления, тем все поставленные цели были достигнуты. задачка решена в полном объеме.

Перечень применяемой литературы

1. Методические указания, создатель Омарбекова А.С.

2. веб ресурс http://citforum.ru/database/articles/umlbases.shtml

3. интерфейс: новейшие направления в проектировании компьютерных систем, создатель Д.Раскин

4. ASE-технологии. Современные способы и средства проектирования информационных систем, создатель неизвестен

]]>