Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Краткая характеристика проектируемой системы).pdf

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

Диаграмма схем состояния указывает:

1.набор состояний системы;

2.действия, которые вызывают переход из 1-го состояния в другое;

3.действия, которые происходят в итоге конфигурации состояния.

Диаграмма деятельности

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

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

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

Диаграмма сотрудничества

Диаграммы сотрудничества показывают взаимодействие объектов функционирования системы. Такие диаграммы моделируют сценарии поведения системы. В русскои? литературе диаграммы сотрудничества нередко именуют диаграммами кооперации.

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

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

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

Графически диаграмма последовательности - разновидность таблицы, которая указывает объекты, размещенные на оси Х, и сообщение упорядоченные по оси У.

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

Каждый объект изображается в виде отдельнои? вертикальнои? колонки. Знак объекта (прямоугольник, снутри которого размещается подчеркнутое имя объекта) помещается сверху колонки, у конца стрелки-сообщения, которое этот объект делает. Если объект существовал еще до первои? операции, изображеннои? на диаграмме, знак объекта изображается в высшей части диаграммы, до всяких сообщений. От него идет пунктирная линия, которая прерываемся в тои? точке, где объект прекращает свое свое существование (опять-таки, если этот момент описывается диаграммои?). Эта линия именуется линией жизни. Точка, в которои? объект прекращает свое существование, отмечается огромным крестом (X), стоящим или у хвоста стрелки, обозначающей сообщение, которое вызывает ликвидирование объекта, или в тои? точке, где объект уничтожает себя сам. Период активности объекта изображается в виде двои?нои? непрерывнои? черты. К такому периоду относится всегда жизни активного объекта либо активация пассивного объекта, - другими словами время, в течение которого производится операция данного объекта (куда врубается также время, затраченное операцией на ожидание возврата из вызванных 100 операций). Если объект вызывает себя рекурсивным образом, прямо либо косвенно, то около первои? двои?нои? непрерывнои? полосы помещается вточности такая же 2-ая. Так изображается двои?ная активация. Порядок расположения объектов не имеет особенного значения, хотя, исходя из убеждений удобства, лучше очень уменьшить расстояние меж линиями жизни, через которое должны проходить стрелки-сообщения. Комментарий относительно активации можно расположить прямо около нее.

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

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

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

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

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

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

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

Заключение

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

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

В соответствии с различными представлениями об организации методики проектирования ИС принято делить на объектные и функциональные (структурные).

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

Существует множество технологий и инструментальных средств, с по-мощью которых можно реализовать оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. Наибольшую популярность в создании проектов ИС, основанных на объектно-ориентированном подходе, получило моделирование с помощью UML.
Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных средств, организационно-экономических, технических систем и других систем различной природы.
С помощью UML можно разработать модель создаваемой системы, которая отображает не только ее концептуальные элементы, такие как функции системы, бизнесc-процессы, конкретные детали системы: классы языков программирования, схемы, БД, повторно используемые компонен-ты ПО.
UML содержит стандартный набор диаграмм и нотаций самых раз-нообразных видов, среди которых популярны диаграммы вариантов использования, диаграммы классов, диаграммы компонентов, диаграммы размещения и проч.

Были разработаны основные составные программного продукта (классы), с помощью которых стало возможно достижение поставленной задачи. Так же были составлены диаграммы классов и UseCase – диаграмма согласно требованиям языка программирования UML.

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

Список использованной литературы

1. Н.Е. Сапожников, Т.А. Беляева, Е.В. Скрябина – Программирование на С++.
2. Севастополь 2004 г.
3. Страуструп Б. Язык программирования С++. Киев: Диасофт,2001. – 900с.,ил.
4. Джефф Элджер Библиотека программиста С++.
5. Конспект лекций по дисциплине Объектно-ориентированное программирование спецзадач.
6. Липпман С. Б. Основы программирования на C++: Пер. с англ. — М.: Вильямс, 2002. — 256 с.
7. Липпман С. Б., Лажойе Ж. Язык программирования С++. Вводный курс: Пер. с англ. — 3-е изд. — М.: ДМК, 2001. — 1104 с.
8. Страуструп Б. Язык программирования C++: Пер. с англ. — 3-е спец. изд. — М.: Бином, 2003. — 1104 с.
9. Страуструп Б. Дизайн и эволюция языка C++.Объектно- ориентированный язык программирования: Пер. с англ. — М.: ДМК пресс, Питер, 2006. — 448 с.
10. Эккель Б. Философия C++. Введение в стандартный C++: Пер. с англ. — 2-е изд. — СПб.: Питер, 2004. — 572 с. [
11. Эккель Б., Эллисон Ч. Философия C++. Практическое программирование: Пер. с англ. — СПб.: Питер, 2004. — 608 с

Приложение А

Cmap

int **KARTA;

int n;

int m;

TImage*im;

Cmap();

~Cmap();

void show_map();

void operator<<(Timage*m);

CPoint

int x;

int y;

CPoint();

CPoint(int x1,int y1)

int get_x();

int get y ();

void set ( int x1,int y1);

void set_x (int x1);

void set_ y(int y1);

Ccar

bool b;

bool vertical;

int v;

int fuel;

int target;

CPoint *point;

Timage*Edit;

TProgress*ProgressBar;

TShape*label;

int x;

int y;

int chislo;

Ccar();

~Ccar();

void show();

void operator<<(TImage *im);

void operator<<(TEdit *ed);

void operator<<(TProgressBar *pr);

void operator<<(TShape *sh);

void operator<<(TLabel *lb);

void stop();

int move();

CNavigator

Cmap map;

Ccar car;

Void operator<<(Timage*im);

Void show();

Приложение Г

Unit1.срр

Приложение Б

#include "Unit1.h"

#include "Unit2.h"

#include "math.h"

//---------------------------------------------------------------------------

#pragma package(smart_init)

#pragma resource "*.dfm"

TForm1 *Form1;

CNavigator navigator;

//---------------------------------------------------------------------------

void __fastcall TForm1::allow_move(int i) {

if (i==1) {

ComboBox1->Enabled=false;

Button1->Enabled=false;

Button2->Enabled=true;

} else {

ComboBox1->Enabled=true;

Button1->Enabled=true;

Button2->Enabled=false;

}

}

//---------------------------------------------------------------------------

void __fastcall TForm1::FormCreate(TObject *Sender)

{

navigator<<Image1;

navigator.car<<Edit1;

navigator.car<<ProgressBar1;

navigator.car<<Shape1;

navigator.car<<Label8;

navigator.show();

show_trees();

}

//---------------------------------------------------------------------------

void __fastcall TForm1::Button1Click(TObject *Sender)

{

allow_move(1);

Timer1->Enabled=true;

}

//--------------------------------------------------------------------------

void __fastcall TForm1::Button2Click(TObject *Sender)

{

allow_move(0);

navigator.car.stop();

Timer1->Enabled=false;