DEPARTAMENTO DE COMPUTAÇÃO CURSO DE PÓS …web.unifil.br/pergamum/vinculos/000006/00000679..pdf · OLIVEIRA, Eder Diego. Elaboração e Aplicabilidade de Mapas Conceituais e Workflow

DEPARTAMENTO DE COMPUTAÇÃO

CURSO DE PÓS-GRADUAÇÃO EM ENGENHARIA DE SOFTWARE COM UML

“LATO-SENSU”

EDER DIEGO DE OLIVEIRA

ELABORAÇÃO E APLICABILIDADE DE MAPAS CONCEITUAIS E WORKFLOW NOS DIAGRAMAS DA UML 2.4 EM UM ESTUDO DE CASO

Londrina

2012



Monografia apresentado à Banca Examinadora

do Curso de Pós-Graduação em Engenharia de

Software com UML do Centro Universitário

Filadélfia de Londrina - UniFil como requisito

parcial para obtenção do grau de Especialista

em Engenharia de Software sob a orientação

da Professora MSc. Simone Sawasaki Tanaka.

LONDRINA

2012



Monografia apresentado à Banca Examinadora do Curso de Pós-Graduação em

Engenharia de Software do Centro Universitário Filadélfia de Londrina - UniFil em

cumprimento a requisito parcial para obtenção do título de Especialista em

Engenharia de Software.

APROVADA PELA COMISSÃO EXAMINADORA

EM LONDRINA, 22 DE MARÇO DE 2012.

Profa. MSc. Simone Sawasaki Tanaka (UniFil) - Orientadora

Prof. MSc. Sergio Akio Tanaka (UniFil) - Examinador

Londrina, 22 de Março de 2012.

Ao Aluno: EDER DIEGO DE OLIVEIRA

Prezado(a) Senhor(a):

Tem a presente a finalidade de NOTIFICAR-LHE nos termos do art. 867 e

seguintes do Código de Processo Civil com vistas a prevenir responsabilidades,

provendo a conservação e ressalva de direitos. A “UniFil” em razão da

apresentação recorrente de trabalhos onde se tem efetuado a cópia de trechos e até

capítulos ou trabalhos inteiros, vem notificá-lo que tal pratica é vedada pela Lei de

Direitos Autorais nº 9.610/98 em seus artigos 1º, 5º incisos VI e X, 7º, 22º, 24º inciso

IV, 29º e 41º, cumulados com a nova redação dos artigos 184 e 186 do Código penal

dados pela lei 10.695/2003, que prevê não apenas a proibição de cópia total ou

parcial sem atribuição da devida autoria como inclusive pena de detenção de até

quatro anos mais multa para quem assim proceder. Assim sendo, considera-se o

aluno: EDER DIEGO DE OLIVEIRA, da Pós-Graduação em Engenharia de Software

com UML, Linha de Formação: Engenharia de Software, ciente de previsão legal que

veda tal prática e se mesmo assim optar por fazê-lo deverá arcar sozinho com o

ônus de tal ato, quer seja ele penal, cível ou administrativo, não podendo a

Instituição de Ensino ser responsabilizada por opção do aluno sem seu

consentimento ou anuência. .

Na esfera administrativa desde já ficam, também devidamente notificados,

que os trabalhos copiados na íntegra ou que apresentem cópia parcial, serão

sumariamente reprovados; bem como estarão sujeitos a outras medidas cabíveis.

Conforme Regulamento da instituição no qual relata o seguinte: “Na constatação de

procedimentos ilícitos para a elaboração dos trabalhos de estágio, caracterizando

cópias parciais ou integrais (plágio), será atribuído a média 0,0 (zero) ao aluno no

bimestre em curso, não cabendo recurso”.

Sem mais para o momento.

Atenciosamente.

Aluno:________________________________________

AGRADECIMENTOS

Agradeço primeiramente a Deus por ter me dado força, muita saúde,

perseverança e força nesta minha caminhada.

Aos meus pais que me incentivaram nessa etapa tão importante da minha

vida.

A minha esposa Carmen por estar comigo em todos os momentos desta

minha caminhada, servindo-me de inspiração.

Ao professores da Pós, que mostraram como e importante este curso para a

formação de profissional em Engenharia de Software para o mercado.

A professora Simone Tanaka que foi a minha orientadora e me ajudou muito

no desenvolvimento deste trabalho.

Aos meus amigos que estiveram dentro de sala de aula comigo me ajudando

e encorajando a concluir mais essa etapa da minha vida, e todos aqueles que me

apoiaram nesta caminhada.

“Para mim, sábio não é aquele que proclama palavras de sabedoria, mas

sim aquele que demonstra sabedoria em seus atos.” (São Gregório).

OLIVEIRA, Eder Diego. Elaboração e Aplicabilidade de Mapas Conceituais e

Workflow nos Diagramas da UML 2.4 em um Estudo de Caso. Londrina, ano

2012. 81f. Monografia - Curso de Pós-Graduação em Engenharia de Software.

Centro Universitário Filadélfia de Londrina - UniFil, Londrina, 2012.

RESUMO

Este trabalho apresenta a aplicação da engenharia de software no sistema de loja

virtual utilizando os quatros novos diagramas da Unified Modeling Language (UML

2.4), tais como: diagrama de tempo, diagrama de estrutura composta, diagrama de

visão geral e diagrama de perfil. Um estudo de caso intitulado iTrade foi utilizado

para demonstrar a aplicabilidade dos modelos com a ferramenta CASE Enterprise

Architect, também foi utilizado para a elaboração e aplicabilidade destes diagramas

um workflow e mapas conceituais, para a aplicação dessas ferramentas foi utilizado

o Bizagi como ferramenta de workflow e o Cmap para criar os mapas conceituais.

Este trabalho contribui para facilitar a criação e a utilização desses diagramas, visto

que os mesmos, ainda, não são tão utilizados por empresas e engenheiros de

software comercialmente.

Palavras-chave: UML; Workflow; Mapas Conceituais.

ABSTRACT

This project reports the application of software engineering in virtual shop system

using the four new diagrams of Unified Modeling Language (UML 2,4), such as:

temple diagram, composite structure diagram, diagram of overview and profile

diagram. A case study titled iTrade was used to demonstrate the applicability of

models with CASE Enterprise Architect tool, was also used for the elaboration and

applicability of these workflow diagrams and conceptual maps, to the implementation

of these tools was used the Bizagi as Cmap and workflow tool to create the

conceptual maps. This project helps to facilitate the creation and use of these

diagrams, since the same aren’t as used by companies and software engineers

commercially

Key words: UML; Workflow; Concept Maps.

LISTA DE FIGURAS

Figura 1 - Visão de como está estruturado os diagrama da UML 2.4. ...................... 20

Figura 2 - Visão dos diagramas estruturais usando mapas conceituais. ................... 21

Figura 3 - Visão dos diagramas comportamentais usando mapas conceituais. ........ 23

Figura 4 - Exemplo de uma colaboração no sistema de venda iTrade ...................... 28

Figura 5 - Exemplo de colaboração composta por partes. ........................................ 29

Figura 6 - Exemplo de um classificador com portas e interfaces. ............................. 30

Figura 7 - Diagrama de Visão Geral de Interação – Processo de Concluir Pedido. .. 33

Figura 8 - Diagrama de Tempo – Linha de Vida de Valor ......................................... 36

Figura 9 - Diagrama de Caso de Uso referente ao Processo Gerenciar Operadora de

Crédito. ...................................................................................................................... 36

Figura 10 - Diagrama de Tempo Gerenciar_Oper_Crédito – Linha Vida de Estado. 38

Figura 11 – Pacote Perfil da classe Produto. ............................................................ 43

Figura 12 – Diagrama de Perfil da Classe Produto. .................................................. 44

Figura 13 - Estrutura dos Diagramas da UML 2.4. .................................................... 48

Figura 14 – Workflow para elaboração do Diagrama de Estrutura Composta........... 49

Figura 15 – Workflow da Atividade de Como Montar o Diagrama de Estrutura

Composta. ................................................................................................................. 50

Figura 16 – Mapa Conceitual do Diagrama de Estrutura Composta. ........................ 55

Figura 17 – Workflow do Diagrama de Visão Geral. ................................................. 56

Figura 18 – Workflow da Atividade Criar o Diagrama de Visão Geral. ...................... 57

Figura 19 – Mapa Conceitual do Diagrama de Visão Geral. ..................................... 62

Figura 20 – Workflow do Diagrama de Tempo. ......................................................... 63

Figura 21 – Workflow da Atividade Elaborar Diagrama de Tempo. ........................... 64

Figura 22 – Mapa Conceitual do Diagrama de Tempo. ............................................. 70

Figura 23 – Workflow do Diagrama de Perfil. ............................................................ 71

Figura 24 – Workflow da Atividade do Diagrama de Perfil. ....................................... 72

Figura 25 – Mapa Conceitual do Diagrama de Perfil. ................................................ 77

LISTA DE QUADROS

Quadro 1 – Componentes que fazem parte do Diagrama de Estrutura Composto. .. 31

Quadro 2 – Componentes que fazem parte do Diagrama de Tempo. ....................... 39

Quadro 3 – Pacote Perfil na extensão XML. ............................................................. 45

Quadro 4 – Componentes que fazem parte do diagrama de Tempo. ....................... 46

Quadro 5 – Atividade “Definir Colaboradores”. .......................................................... 51

Quadro 6 – Atividade “Identificar Papéis”. ................................................................. 52

Quadro 7 – Atividade “Verificar Ocorrência de Colaboração”. ................................... 53

Quadro 8 – Elaborar “Diagrama de Estrutura Composta”. ........................................ 55

Quadro 9 – Atividade “Estabelecer Foco do Diagrama”. ........................................... 59

Quadro 10 – Atividade “Definir Quadro de Interação” ............................................... 60

Quadro 11 – Atividade “Definir Ocorrência de Interação” .......................................... 61

Quadro 12– Elaborar “Diagrama de Visão Geral” ..................................................... 62

Quadro 13 – Atividade “Estabelecer Foco do Diagrama” .......................................... 66

Quadro 14 – Atividade “Definir Estados”. .................................................................. 67

Quadro 15 – Atividade “Definir Eventos”. .................................................................. 68

Quadro 16 – Atividade “Definir Tempo de Execução de cada Transição”. ................ 69

Quadro 17 – Elaborar Diagrama de Tempo. ............................................................. 70

Quadro 18 – Atividade “Estabelecer Foco do Diagrama” .......................................... 74

Quadro 19 – Atividade “Definir Metamodelos”. .......................................................... 75

Quadro 20 – Atividade “Definir Estereótipos”. ........................................................... 76

Quadro 21 – Elaborar Diagrama de Perfil. ................................................................ 77

LISTA DE ABREVIATURAS E SIGLAS

UC – Caso de Uso

UML – Linguagem de Modelagem Unificada

OOA – Análise Orientada a Objetos

OMT – Técnica de Modelagem de Objetos

OOSE – Engenharia de Software Orientada a Objetos

OO – Orientação a Objetos

OMG – Object Management Group

TCC – Trabalho de Conclusão de Curso

MOF – Facilidade de Meta Objetos

XML – Linguagem Extensível de Marcação

SUMÁRIO

1 INTRODUÇÃO ................................................................................................ 15

2 REVISÃO DE LITERATURA........................................................................... 17

2.1 WORKFLOW ....................................................................................................... 17

2.2 MAPAS CONCEITUAIS ...................................................................................... 18

2.3 UML ..................................................................................................................... 19

2.3.1 Diagramas Estruturais ................................................................................... 21

2.3.2 Diagramas Comportamentais ........................................................................ 23

3 DIAGRAMA ESTRUTURA COMPOSTA ........................................................ 27

3.1 COLABORAÇÕES .............................................................................................. 27

3.2 PROPRIEDADES E PARTES ............................................................................. 28

3.3. PAPÉIS .............................................................................................................. 29

3.4. PORTAS ............................................................................................................. 30

4 DIAGRAMA DE VISÃO GERAL ..................................................................... 32

5 DIAGRAMA DE TEMPO ................................................................................. 35

6 DIAGRAMA DE PERFIL ................................................................................. 40

6.1. POSICIONAMENTOS DE PERFIS ENTRE METAMODELOS MOF E UML ...... 40

6.2. HISTÓRIA DE PERFIL E OS REQUISITOS DE PROJETO ............................... 40

7 IMPLEMENTAÇÃO DO MAPA CONCEITUAL E DO WORKFLOW .............. 47

7.1 ESTRUTURA DOS DIAGRAMAS DA UML. ........................................................ 47

7.2 MAPA CONCEITUAL E WORKFLOW DO DIAGRAMA DE ESTRUTURA

COMPOSTA. ............................................................................................................. 48

7.3 MAPA CONCEITUAL E WORKFLOW DO DIAGRAMA DE VISÃO GERAL ....... 56

7.4 MAPA CONCEITUAL E WORKFLOW DO DIAGRAMA DE TEMPO. ................. 63

7.5 MAPA CONCEITUAL E WORKFLOW DO DIAGRAMA DE PERFIL................... 71

8 CONCLUSÕES E TRABALHOS FUTUROS .................................................. 78

REFERÊNCIAS ......................................................................................................... 80

1 INTRODUÇÃO

Para se criar um software de qualidade deve se respeitar diretrizes que

ajudem a desenvolver esse processo. Para isso é usado à engenharia de software

que cria padrões a serem seguidos para que os software criados sejam de

qualidade. Dentro desse seguimento foi padronizado e criado a Unified Modeling

Language (UML). A UML é uma linguagem de modelagem utilizada mundialmente

para se modelar software de qualidade e também para ajudar a aumentar a

produtividade dos software desenvolvidos.

Como a maioria dos padrões utilizados, a UML é um padrão muito extenso,

sendo assim, foi dividido em quatorze diagramas, cada diagrama tem uma função

específica dentro do desenvolvimento de um software de qualidade. Mas nem

sempre todos esses diagramas são utilizados no desenvolvimento de um software,

muitas vezes as pessoas que estão modelando esse software não têm o

conhecimento da importância desses diagramas no desenvolvimento do software,

uma vez que esse novos diagramas (estrutura composta, visão geral, tempo e perfil)

não são abordados em uma graduação, e nem tem tantas referências bibliográficas

no mercado.

Levando em consideração esses aspectos viu se a necessidade de elaborar

um mecanismo que venha facilitar a criação e aplicação deste diagrama. Neste

estudo foi descrito os componentes e aspectos que fazem parte da estrutura desses

diagramas mostrando a importância de cada um no desenvolvimento de software.

Os diagramas que foram elaborados neste estudo são os seguintes: estrutura

composta, visão geral, tempo e perfil; mostrando a sua aplicabilidade no

desenvolvimento de um sistema de loja virtual. Como ferramenta de auxilio para a

elaboração e aplicação desses diagramas utilizou se mapas conceituais e workflows.

Este trabalho esta dividido nos seguintes capítulos, o capítulo 2 apresenta

a revisão de literatura onde será contextualizado o que é: workflow, mapas

conceituais e uma introdução bem sucinta sobre UML e seu diagramas. Já nos

capítulos 3, 4, 5 e 6 será contextualizado os diagramas: de estrutura composta,

visão geral, tempo e perfil respectivamente. Já no capítulo 7 serão apresentados os

mapas conceituais e os workflows desses diagramas, no capítulo 8 será

apresentada a conclusão e trabalhos futuros.

JUSTIFICATIVA PARA A ELABORAÇÃO DESTE TRABALHO É QUE

a UML é uma linguagem de modelagem muito extensa, nem sempre todos

os seus diagramas são utilizados pelos analistas na modelagem de um software. E

com o surgimento de novos diagramas notou-se a necessidade de elaborar

mecanismos que facilite a criação e a aplicação destes diagramas. O objetivo deste

estudo é mostrar a aplicabilidade deste diagrama no desenvolvimento de software,

para facilitar a elaboração deste diagrama foram utilizadas as ferramentas de

workflow e mapas conceituais.

Os objetivos deste trabalho foram:

facilitar a elaboração e a aplicabilidade dos diagramas, “Perfil, Tempo,

Estrutura Composta e Visão Geral” da UML 2.4, utilizando workflow e mapas

conceituais. Em relação aos objetivos específicos foram tratados os seguintes itens:

integrar os diagramas;

ter maior clareza na elaboração e aplicabilidade dos diagramas na

prática;

auxiliar a definição dos componentes que farão parte deste diagramas.

2 REVISÃO DE LITERATURA

Neste capítulo serão apresentados os conceitos e a importância de

workflow, mapas conceituais e a UML juntos com uma breve descrição de todos os

seus outros diagramas que não farão parte deste estudo.

2.1 WORKFLOW

Workflow pode ser um sistema ou alguma atividade baseadas em processo,

onde o processo é “um conjunto de um ou mais procedimentos ou atividade

relacionada, os quais coletivamente atingem um objetivo dentro de uma estrutura

organizacional que define papéis funcionais e relações” (TELECKEN, 2009).

O conceito de workflow se refere a uma coleção de atividades (processo)

que permanecem juntas porque são executadas como consequência de um evento

especifico (JOOSTEN, 95).

Ela é uma tecnologia que possibilita relacionar e potencializar a

automatização de processos por meios da organização e da tecnologia. Dessa

forma, torna-se uma ferramenta de grande auxílio para o professor demonstrar as

atividades e as tarefas de cada diagrama da UML, facilitando assim a visualização

dos relacionamentos e a dependência de cada diagrama por parte dos alunos.

Teoricamente pode-se dizer que outros conceitos que são necessários para

um bom entendimento do que é workflow são:

atividade é um conjunto de eventos que pode ser realizado por vários

atores sobre a responsabilidade de um ator para executar a lógica de

todo processo;

processo é o conjunto de atividade que possuem os mesmos objetivos

dentro da ligação lógica do workflow. Um workflow também pode ser

considerado um processo, pois um processo pode ter vários

subprocesso (TELECKEN, 2009);

papel pode estar associado a um tipo de usuário que pode executar

uma atividade ou ser responsável pela mesma;

ator pode assumir um papel e executar uma atividade dentro de uma

instância do workflow;

instância representa uma única ocorrência de workflow em execução

incluído seus dados (TELECKEN, 2009).

Cada atividade do workflow deve prover produtos advindos das atividades

anteriores que serão utilizados na atividade corrente, bem como a metodologia a ser

utilizada nas atividades na qual e descrita por uma instrução de trabalho (TANAKA,

2009a).

2.2 MAPAS CONCEITUAIS

Mapa conceitual é uma ferramenta conceitual de grande valia para a

representação do conhecimento, segundo seu criador John Novak, um mapa

conceitual são representações gráficas semelhantes a diagrama que podem ser

descrito como um conjunto de conceitos, representados através de nós

interrelacionados, que expressam o conhecimento existente sobre um assunto. A

relação entre dois ou mais conceitos é feita através de linhas entre eles. Para

evidenciar um relacionamento entre conceitos, são colocadas palavras de ligação

formando assim proposições simples que mostram o significado do vínculo.

Embora normalmente mapas conceituais tenham uma organização

hierárquica e, muitas vezes incluam setas, esse diagrama não deve ser confundido

com organogramas ou diagrama de fluxo, pois não implicam sequência,

temporalidade ou direcionalidade, nem hierarquias organizacionais. Os mapas

conceituais são diagramas de significados, de relações significativas, de hierarquia

se for o caso.

Os mapas conceituais são classificados de forma onde os conceitos sejam

dispostos por ordem de importância. Os conceitos mais gerais são apresentados em

um nível mais alto da estrutura, e os conceitos mais específicos vão sendo

acrescentados em um nível inferior. Durante a construção de um mapa é preciso

considerar que um conceito irá aparecer em uma única vez e que em algumas

situações, linhas são finalizadas com uma seta, a fim de indicar um conceito que foi

derivado.

Uma ou duas palavras chaves escritas sobre essas linhas podem ser

suficientes para explicar a natureza dessa relação. Deve-se explicar quais os

motivos de se ter criado mapas conceituais, ao explicá-los, a pessoa expõe

significados. Reside ai o maior valor de um mapa conceitual.

Como uma ferramenta de aprendizagem, o mapa conceitual é útil para o

estudante fazer anotações, resolver problemas, planejar o estudo e preparar-se para

avaliações. Para os professores os mapas podem auxiliar em suas tarefas rotineiras,

tais como: ensino de um novo tópico, reforço da compreensão, verificação da

aprendizagem, identificação de conceitos mal compreendidos e avaliação (BARROS,

2008).

2.3 UML

A Unifed Modeling Language (UML) é resultado da unificação de três

métodos de modelagem o Object Oriented Analysis (OOA) de Grady Booch, que

identificava as classes e os objetos e definia o relacionamento entre eles. O método

Object Modeling Technique (OMT) de James Rumbaugh que propôs que as

atividades de análise deveriam criar três modelos, sendo um de objetos, responsável

pela representação dos objetos, classes, hierarquias e relacionamentos; um

dinâmico que representa os comportamentos; um funcional, que representa o fluxo

de informação através do sistema. E o método Object Oriented Software Enginnering

(OOSE) de Ivar Jacobson que tem forte ênfase no uso dos chamados casos de uso,

que representa uma descrição do cenário.

A UML é uma linguagem de modelagem visual utilizada para modelar

software baseados no paradigma de Orientação a Objetos (OO). Nos últimos anos

tornou-se a linguagem padrão adotada internacionalmente para modelagem de

software (GUEDES, 2009). Deve ficar bem claro que a UML não é uma linguagem

de programação e sim uma linguagem de modelagem, uma notação ao qual o intuito

é auxiliar os engenheiros, analistas e programadores a definirem as características

dos softwares, tais como levantamento e requisitos, comportamentos, estrutura

lógica e até mesmo a estrutura física dos equipamentos utilizados na implantação do

sistema.

Ela pode ser empregada para visualizar, especificar e documentar artefatos

na construção de um sistema complexo de software. Como se trata de uma

linguagem visual ela é toda representa em forma de símbolos.

Para Grady Booch (2005), um dos criadores da UML, diz que esse método

deve atingir quatro objetivos:

ajudar a equipe de projeto e desenvolvimento a visualizar um sistema

como ele é ou como ele pretende ser ao final de seu desenvolvimento;

ajudar a especificar a estrutura ou o comportamento do sistema;

proporcionar um modelo que sirva de guia para a construção de um

sistema;

documentar as decisões tomadas pela equipe de desenvolvimento.

A UML 2.4 é composta por 14 (quatorze) diagramas, classificado em

diagramas estruturais e comportamentais, na Figura 1 mostra como está estruturado

esses diagramas na sua visão geral.

Figura 1 - Visão de como está estruturado os diagrama da UML 2.4.

2.3.1 Diagramas Estruturais

Os diagramas estruturais mostram a estrutura estática dos objetos em um

sistema, ou seja, eles descrevem os elementos específicos que são independentes

do tempo. O elemento de um diagrama de estrutura representa os conceitos

significativos de uma aplicação e pode incluir conceitos abstratos do mundo real

(OMG, 2011b).

Eles existem para visualizar, especificar, construir e documentar os aspectos

estáticos do sistema, ou seja, representa o seu esqueleto e suas estruturas, na

Figura 2 mostra os diagramas que fazem parte da estrutura estática da UML 2.4.

Figura 2 - Visão dos diagramas estruturais usando mapas conceituais.

Digramas de Classes: esse diagrama apresenta uma visão estática

de como as classes estão organizadas, preocupando-se em como

definir sua estrutura lógica. Seu principal enfoque está em permitir a

visualização das classes que farão parte do sistema, assim como seus

respectivos atributos e métodos.

Diagramas de Componentes: este diagrama identifica os

componentes que fazem parte do sistema ou de um subsistema. Um

componente pode representar tanto um componente lógico (um

componente de negócio ou de processo) ou ainda um componente

físico como arquivos de código fonte, arquivos de ajuda ou ainda

arquivos executáveis.

Diagramas de Pacotes: este diagrama descreve como os elementos

do modelo estão organizados em pacote e demonstra as dependências

entre eles. Esse diagrama é muito útil para modelagem de subsistemas

e para a modelagem de subdivisões da arquitetura de uma linguagem,

também pode ser utilizado para representar um conjunto de sistema

integrado. Um pacote pode representar um sistema, um subsistema,

uma biblioteca ou um processo de desenvolvimento (GUEDES, 2009).

Diagramas de Implantação: o diagrama de implantação é o diagrama

com visão mais física da UML, ele especifica um conjunto de

construções que pode ser utilizado para definir a arquitetura de

execução de um sistema que representa a atribuição de artefatos de

software para nós. Um nó pode representar um hardware (computador,

impressora) como um servidor onde um ou mais módulos de software

são executados ou que armazene algum tipo de arquivo que será

consultado pelos módulos do sistema. Um nó também pode

representar um ambiente de execução, ou seja, um ambiente que

suporta o sistema de alguma forma.

Diagramas de Objetos: esse diagrama tem como objetivo fornecer

uma visão dos valores armazenados pelos objetos das classes,

definidos no diagrama de classes em um determinado momento do

sistema. O diagrama de objeto é muito parecido com o diagrama de

classe, mais esse diagrama não apresenta métodos, somente

atributos.

Diagrama de Estrutura composta: esse diagrama destina-se à

descrição dos relacionamentos entre os elementos ele introduz um

ponto de conexão entre os elementos modelados, a quem pode se

modelar interface. Esse diagrama também pode ser usado para

modelar colaborações em tempo de execução.

Diagrama Perfil: esse diagrama contém mecanismos que permitem as

metaclasses e os metamodelos existentes serem estendidos para

adaptá-los para diferentes fins. Isto inclui a capacidade de adaptar o

metamodelo UML para diferentes plataformas com o J2EE ou .Net.

2.3.2 Diagramas Comportamentais

Os diagramas comportamentais mostram o comportamento dinâmico dos

objetos em um sistema, incluindo seus métodos, colaborações, atividades e estados.

O comportamento dinâmico de um sistema pode ser descrito como uma série de

mudanças no sistema ao longo do tempo (OMG, 2011b).

Eles são usados para visualizar, especificar, construir e documentar os

aspectos dinâmicos de um sistema (OMG, 2011b), na Figura 3 mostra os diagramas

que fazem parte do comportamento dinâmico UML 2.4.

Figura 3 - Visão dos diagramas comportamentais usando mapas conceituais.

Diagramas de Atividade: a modelagem de atividade enfatiza a

sequência e as condições para coordenar comportamento de baixo

nível. O diagrama de atividade é o diagrama com maior ênfase ao nível

de algoritmo da UML e provavelmente um dos mais detalhistas. Esse

diagrama é usado para modelar atividades que podem ser um método

ou um processo completo.

Diagramas de Caso de Uso: os diagramas de casos são usados para

capturar os requisitos de um sistema, isto é, o que o suposto sistema

pode fazer. Os conceitos chave associados ao diagrama de caso de

uso são os atores e casos de uso. Os atores representam os papéis

desempenhados pelos diversos usuários que poderão de alguma forma

utilizar, os serviços e funções do sistema. Eventualmente um ator pode

representar algum hardware especial ou mesmo um software que se

interaja com o sistema. Os casos de uso referem-se aos serviços,

tarefas ou funcionalidades que podem ser utilizados de alguma

maneira pelos atores que interagem com o sistema, sendo utilizados

para expressar e documentar os comportamentos pretendidos para

cada função.

Diagramas de Máquina de Estado: o diagrama de máquina de estado

define um conjunto de conceitos que podem ser usados para modelar o

comportamento através do estado de transição de um sistema. Além

de expressar o comportamento de uma parte do sistema o diagrama de

estado também pode ser usado para expressar o protocolo de uso de

parte do sistema. Estes dois tipos de máquinas de estado são referidos

aqui como máquina de estado comportamental e máquina de estado de

protocolo. O diagrama de máquina de estado comportamental pode ser

usado para especificar o comportamento dos diversos elementos do

modelo. O elemento modelado muitas vezes é uma instância de uma

classe. O diagrama de máquina de estado de protocolo expressa a

transição legal que um classificador pode desencadear. A notação

máquina de estado é uma forma conveniente para definir um ciclo de

vida de um objeto, ou uma ordem de invocação de seu funcionamento

(OMG, 2011b).

Os diagramas de interação são usados para obter uma melhor

compreensão de uma situação de interação para um designer individual ou para um

grupo, para alcançar um entendimento comum da situação. Interação também é

utilizada na fase de projetos mais detalhados onde o processo de comunicação deve

ser definido de acordo com os protocolos formais. O diagrama de interação descreve

os conceitos necessários para expressar interações dependendo de suas

finalidades. Uma interação pode ser exibida em diversos diagramas: diagrama de

sequência, diagrama de comunicação, diagrama de visão geral de interação e

diagrama de tempo, cada tipo de diagrama fornece uma visão ligeiramente diferente

que o torna mais apropriado para cada fase do projeto. (OMG, 2011b).

Diagramas de Sequência: este diagrama procura determinar a

sequência de eventos que ocorreram em um determinado processo e

identificar quais mensagens deve ser disparadas entre os elementos

envolvidos e em que ordem eles podem aparecer. O diagrama de

sequência baseia-se nos diagramas de caso de uso, havendo a

necessidade de um diagrama de sequência para cada caso de uso

declarado. O diagrama de sequência depende também do diagrama de

classe, já que as classes dos objetos utilizados no diagrama de

sequência estão descritas nele.

Diagramas de Comunicação: o diagrama de comunicação está

amplamente associado ao diagrama de sequência, na verdade um

complementa o outro. As informações são praticamente as mesmas

apresentadas no diagrama de sequência. Porém com o enfoque

diferente, visto que, esse diagrama não se preocupa com a

temporalização do processo. O diagrama de comunicação concentra-

se em como os objetos estão vinculados através de mensagens, outra

característica do diagrama é que as mensagens possuem numeração

para mostrar a sua sequência.

Diagrama de Visão Geral: o diagrama de visão geral e uma variação

do diagrama de atividade. Seu objetivo é fornecer uma visão geral do

controle de fluxo, esse diagrama permite a captura de uma perspectiva

estática dos fluxos de interação entre os componentes do sistema de

forma geral.

Diagrama de Tempo: esse diagrama apresenta algumas semelhanças

com o diagrama de máquina de estado. No entanto, ele enfoca as

mudanças de estado de um objeto ao longo do tempo. O diagrama de

tempo é usado para mostrar interações quando um objeto principal de

um diagrama é a razão sobre o tempo.

3 DIAGRAMA ESTRUTURA COMPOSTA

Esse diagrama introduz um ponto de conexão dos elementos modelados, a

quem pode se associar interfaces. Também utiliza a noção de colaboração, que

consiste em um conjunto de elementos que são interligados através de seus pontos

de conexão (portos) para execução de uma funcionalidade específica.

O termo “estrutura” usado nesse diagrama refere-se a uma composição de

elementos interconectados, representado instâncias de tempo de execução

colaborando por meio de conexões de comunicação para alcançar um objetivo

comum. Esse diagrama também fornece mecanismo para especificar e descrever a

estrutura interna de um classificador.

3.1 COLABORAÇÕES

Os objetos em um sistema normalmente cooperam entre si para produzir o

comportamento de um sistema. O comportamento é a funcionalidade necessária

para programar o sistema.

O comportamento de uma colaboração acabará por exibir um conjunto de

instâncias cooperantes que se comunicam umas com as outras através do envio de

sinais ou de invocar operações. No entanto, para compreender os mecanismos

utilizados em um projeto, pode ser importante descrever apenas os aspectos

classificadores e suas interações, que estão envolvidas na realização de uma tarefa

ou um conjunto de tarefas relacionadas.

Uma colaborações permitem descrever apenas os aspectos relevantes da

cooperação de um conjunto de casos, identificando os papéis específicos que as

instâncias vão usar. O propósito primário de uma colaboração é explicar como um

sistema funciona, portanto, apresenta somente os aspectos extremamente

necessários. Um mesmo objeto pode estar interpretando simultaneamente diversos

papéis em diferentes colaborações, mas cada colaboração deverá representar

somente os aspectos relevantes ao seu propósito, conforme representado na Figura

4 exemplo de colaboração no sistema vendas iTrade.

Figura 4 - Exemplo de uma colaboração no sistema de venda iTrade

Note que dentro da colaboração da classe Venda existem mais quatro

classes que colaboram de alguma forma com a venda, toda venda tem um produto,

para toda venda de um produto o mesmo precisa conter no estoque, para o produto

existir precisa haver um fabricante e para a distribuição deste produto sempre

haverá um fornecedor.

3.2 PROPRIEDADES E PARTES

Uma propriedade representa um conjunto de instância interna, que são

possuídas por uma instância de um classificador container. Quando uma instância

de um classificador é criada, um conjunto de instâncias correspondentes às suas

propriedades pode ser criado também. Esse conjunto é subconjunto do conjunto

total de instância especificado pelo classificador que define a propriedade.

Uma parte declara que uma instância desse classificador pode conter um

conjunto de instâncias por composição, ou seja, essas instâncias não podem

relacionar-se com outro objeto, pois pertencem exclusivamente à instância da classe

container e serão destruídas quando essa instância for destruída. Conforme

representado na Figura 5.

Figura 5 - Exemplo de colaboração composta por partes.

Note que se a classe produto for destruída, automaticamente as classes

fornecedor, fabricante e estoque também serão, visto que para a ocorrência de uma

venda terá que ter associado a ela um produto e todo produto tem a ele associado

um fornecedor, um fabricante, para toda venda sempre terá que haver um produto

em estoque.

3.3. PAPÉIS

Os “papéis” de uma colaboração são interpretados por instâncias que

cooperam entre si para concluir uma tarefa. Os relacionamentos entre as instâncias,

considerados relevantes para a tarefa em questão, são representados por meio de

linhas que ligam uma instância a outra, chamada de conectores.

Os papéis de colaborações definem um uso de instâncias, enquanto os

classificadores que definem esses papéis especificam todas as propriedades

requeridas dessas instâncias. Sendo assim uma colaboração especifica quais

propriedades uma instância dever ter habilitadas.

3.4. PORTAS

Uma porta é uma propriedade de um classificador que especifica um ponto

de interação distinto entre um classificador e seus ambientes ou entre um

classificador e suas partes internas. As portas são conectadas às propriedades dos

classificadores através de conectores. Aos quais os pedidos podem ser feitos para

invocar as características comportamentais de um classificador. As portas podem

especificar os serviços que um classificador fornece para seus ambientes, bem

como os serviços que um classificador espera para seus ambientes. Portas são

representadas por quadrados sobrepostos à borda de um classificador ou de suas

partes internas, a Figura 6 mostra um exemplo de classificador com portas e

interfaces.

Figura 6 - Exemplo de um classificador com portas e interfaces.

Note que a classe Endereço é a porta e as classes Cidade e Pessoa são as

interfaces, todo endereço têm associado a ele uma cidade e toda pessoa também

tem a ele associado um endereço.

Para um melhor entendimento da notação utilizada no diagrama de estrutura

composta foi elaborado o Quadro 1 com a descrição de todos os componentes.

Tipo de Nó Notação Descrição

Partes

Declara que uma instância desse

classificador pode conter um

conjunto de instâncias por

composição.

Portas

Uma porta é uma propriedade de

um classificar que especifica um

ponto de interação distinto entre um

classificador e seus ambientes ou

entre um classificador e suas partes

internas.

Colaboração

Uma colaboração descreve uma

estrutura de elementos a colaborar,

cada um executando uma função

especializada, que coletivamente

realiza alguma função desejada.

Conector ________________ Especifica a ligação que permite a

comunicação entre duas ou mais

instâncias

Quadro 1 – Componentes que fazem parte do Diagrama de Estrutura Composto.

composite structure D...

ProdutoVenda

4 DIAGRAMA DE VISÃO GERAL

O diagrama de visão geral é uma variação do diagrama de atividade. Seu

objetivo é fornecer uma visão geral do controle de fluxo, esse diagrama permite a

captura de uma perspectiva estática dos fluxos de interação entre os componentes

do sistema de forma geral.

Este diagrama utiliza quadros no lugar dos nós de ações, embora também

utilize símbolos como o nó de decisão e o nó inicial. Existem neste diagrama

basicamente dois tipos de quadro: quadro de interação que pode conter qualquer

tipo de diagrama de interação da UML, e quadros de ocorrência de interação, que

normalmente fazem uma referência a um diagrama de interação.

No exemplo mostrado na Figura 7 estão os quadros de interação referentes

aos processos de Adicionar Produto ao Carrinho que contém um diagrama de

sequência e 4 (quatro) quadros de ocorrência de interação referente ao processo de

Realizar Login, Cadastrar Login, Visualizar Carrinho de Produto e Concluir Pedido.

O diagrama se inicia com um quadro de interação do processo de Adicionar Produto ao Carrinho, onde o cliente adiciona um produto através da interface.

Essas informações são repassadas para a controladora, que dispara o método

Adicionar_Produto em um objeto da classe Produto, que por sua vez dispara o

método Produto_Disponível em um objeto da classe Estoque. Esse método retorna

verdadeiro (caso o produto esteja disponível) representado a quantidade de produto

que o cliente solicitou. De posse da quantidade do produto é disparado um método

de P.Adic Sucesso em um objeto da classe ProdutoVenda, que por sua vez

dispara o mesmo método para a controladora e esse produto é visualizado pelo

cliente através da interface.

Após o término desse processo, é feito um teste onde se verifica se o cliente

está logado ao sistema, se o cliente estiver logado ele visualiza o carrinho de

compra com os produtos escolhido por ele. Se o cliente não estiver logado

aparecerá à opção Realizar Login, caso o mesmo não estiver cadastro no sistema

aparecerá à opção Cadastrar Login.

Realizados estes processos, é feito um novo teste, onde o cliente confirma

ou não a conclusão do pedido. Caso confirme o pedido aparecerá à mensagem

confirmar pedido e ele irá para a fase de pagamento. Caso contrário o pedido será

cancelado e a mercadoria será liberada novamente para o estoque. A Figura 7

mostra um exemplo de como ficará este diagrama depois de modelo.

Figura 7 - Diagrama de Visão Geral de Interação – Processo de Concluir Pedido.

Note que esse diagrama tem seu primeiro quadro aberto onde ele é

representado como um diagrama de sequência, onde se pode ver toda a sequência

que irá acontecer para se adicionar um produto ao carrinho. Já os outros quadros

também poderiam ser apresentados com um diagrama de sequência, porém o

diagrama ficaria muito grande, fugindo um pouco do seu foco que é de ser o mais

sucinto possível.

5 DIAGRAMA DE TEMPO

O diagrama de tempo apresenta algumas semelhanças com o diagrama de

máquina de estado. No entanto, ele enfoca as mudanças de estado de um objeto ao

longo do tempo. O diagrama de tempo é usado para mostrar interações quando um

objeto principal de um diagrama é a razão sobre o tempo.

A cronometragem do diagrama foca na condição de mudança dentro das

linhas de vida, ao longo de um eixo de tempo linear. O diagrama de tempo descreve

o comportamento dos classificadores individuais e os classificadores de interações,

focando a atenção na ocorrência de eventos que causam mudança na condição

modelada pela linha de vida.

É importante destacar que o diagrama de tempo tem duas formas de

representação: uma notação mais simples chamada de linha de vida de valor, e

outra mais robusta onde as etapas são representadas em uma forma semelhante a

um gráfico, chamada de linha de vida de estado.

No exemplo da Figura 8 é utilizado a forma mais simples, ou seja, a linha de

vida de valor onde são descritas as etapas percorridas por um aluno para a

conclusão de curso em uma universidade (o objeto da linha de vida), desde a

elaboração de seu pré-projeto até a entrega final de seu trabalho de conclusão de

curso (TCC). Cada etapa ou estado do objeto da classe Conclusão de Curso é

apresentado por meio de hexágono. Note que o primeiro e o último estado

encontram se abertos acima de cada etapa do processo, e as restrições de duração

de tempo se encontram entre as barras verticais de cada Estado. No caso do estado

Criação Pré-Projeto o aluno tem o período que vai do dia 25 de fevereiro até 01 de

junho, já o no estado Entrega Final do TCC o aluno tem até 13 de dezembro para

concluir seu trabalho.

Figura 8 - Diagrama de Tempo – Linha de Vida de Valor

Já o exemplo apresentado na Figura 10, se dará na forma mais robusta

deste diagrama, linha de vida de estado, onde as mudanças de um estado para

outro é determinado por um gráfico, onde o analista pode descrever e determinar

qual evento causou a mudança de estado, isso é se ele considerar necessário para

o projeto em que está sendo construído. O diagrama que iremos modelar é referente

ao processo de gerenciar operadora de crédito. A Figura 9 mostra o digrama de caso

de uso referente a esse processo.

Figura 9 - Diagrama de Caso de Uso referente ao Processo Gerenciar Operadora de Crédito.

Primeiro, cria-se duas linhas de vida de estado, que representará a

transação aprovada e a transação cancelada. Em seguida são inseridos seus

possíveis estados para cada objeto. Feito isso o próximo passo será definir as

transações que irão ocorrer.

O primeiro estado foi definido como Inicializada, onde será definida qual a

bandeira do cartão de crédito, e em quantas parcelas será feito a compra e serão

inseridos também os dados do cartão, como número do cartão, código de segurança

do cartão, data de validade do cartão e o nome do cliente que esta no cartão, essa

transação demorará em torno 40 segundos.

Já o segundo estado que é chamada de estado Em andamento que

representa o registro de dados do cliente no servidor da Cielo, (este analise foi feito

apartar dos dados da Cielo no sítio “http://pt.scribd.com/doc/55887698/Manual-Do-

Desenvolvedor-1-5-6”) essa transação terá uma duração aproximada de 13

segundos.

Já o estado Autenticado, indica que a transição foi aprovada pelo emissor

do cartão de crédito, o tempo de execução será de aproximadamente 11 segundos.

Depois da realização deste processo a compra já poderá ser autorizada para

separação no estoque. Já o estado Capturado representa a autorização de

recebimento da loja junto à operadora do cartão de crédito essa transação pode

demorar de 1 a 5 dias.

Como toda transição de crédito esta transação também esta sujeita a ser

negada pela operado de crédito. Note que antes da transação passar para o estado

Autenticado, há uma seta (mensagem) que indica uma restrição, se isso ocorrer

indica que a transação foi negada, passando assim pra a próxima linha de vida

(Transação Negada) do diagrama. O estado Não Autenticado indica que a

transação não foi autorizada pela operadora de crédito, sendo assim, é possível

notar que o tempo de resposta desta transação é de 33 segundos, o que representa

que antes de obter a resposta de transação não autorizada o sistema teve que

passar pelos estados de Inicializada e Em Andamento. Logo após acontecido esse

evento a transação irá para o estado de Não Capturado isso indica que a transação

não foi aprovada e que o lojista não tem nenhum crédito a receber da operada de

crédito referente a essa transação isso levará aproximadamente 20 segundos para

acontecer. O último estado desta transição é a Cancelada isso indica que a

transação foi suspensa, conforme representado na Figura 10.

Figura 10 - Diagrama de Tempo Gerenciar_Oper_Crédito – Linha Vida de Estado.

Para um melhor entendimento da notação utilizada no diagrama de tempo foi

elaborado o Quadro 2 com a descrição de todos os componentes.

Tipos de caminho Notação Descrição

Quadro

Mostra uma moldura

retangular ao redor do

diagrama, com um nome em

um compartimento no canto

superior esquerdo onde

estará escrito o evento que

irá ocorrer.

Mensagem

Uma mensagem pode vir de

ambos os lados dependendo

do tipo de mensagem que é

transmitida.

Rotulo de Mensagem Os rótulos são apenas

notações abreviadas.

Linha de Vida de

Estado

Linha de Vida de

Valores

Permite um estado do

classificador ou atributo ou

alguma condição testável,

com um valor. Também

permite deixar um estado

continuo, isto é deixar

ilustrativo um cenário que em

determindas situações sofrem

mudanças no seu estado tais

como temperatura ou

densidade.

Quadro 2 – Componentes que fazem parte do Diagrama de Tempo.

6 DIAGRAMA DE PERFIL

O diagrama de perfil contém mecanismos que permitem as metaclasses e os

metamodelos existentes serem estendido para adaptá-los para diferentes fins. Isto

inclui a capacidade de adaptar o metamodelo UML para diferentes plataformas com

o J2EE ou .Net, o mecanismo de perfis é consistente com a OMG Meta Object

Facility (MOF). (OMG, 2011b).

6.1. POSICIONAMENTOS DE PERFIS ENTRE METAMODELOS MOF E UML

A especificação de infraestrutura é reutilizada em vários meta-níveis em

diversas especificações da Object Management Group (OMG) que lida com a

modelagem. Por exemplo, Meta Object Facility (MOF) usa-o pra fornecer uma

capacidade de metamodelos, enquanto que a superestrutura da UML usa-o para

modelar o modelo UML.

Esta cláusula trata de casos de uso comparáveis ao MOF na meta-nível, que

é um nível maior do que o resto das especificações da superestrutura. Para permitir

isso o metamodelo de referência deve ser definido como uma instância da UML que

corresponde à sua definição usando o MOF. Assim ao definir um perfil em UML os

estereótipos são definidos para estender as classes UML na versão normativa do

metamodelo UML.

A primeira abordagem utilizada para atingir esse objetivo constitui-se em

definir o núcleo comum, representado pelo pacote Núcleo (Core). Esse pacote

permite que os elementos de modelo sejam compartilhados entre a UML e a MOF. A

segunda abordagem constitui-se em definir a UML como um modelo baseado no

metamodelo MOF (GUEDES, 2009).

6.2. HISTÓRIA DE PERFIL E OS REQUISITOS DE PROJETO

O mecanismo de perfil foi definido especificamente para fornecer um

mecanismo de extensão leve para o padrão UML. Na UML 1.1 os estereótipos e

valores etiquetados foram utilizados como extensões baseados em um texto que

pode ser anexado aos elementos do modelo da UML de forma flexível. Nas versões

posteriores da UML a noção de um Perfil foi definida de forma a fornecer uma

estrutura mais precisa para a definição dos estereótipos e valores das tags. Já na

UML 2 a infra-estrutura e as especificações de superestruturas foram definidas como

meta técnica especifica de modelagem.

Os seguintes requisitos têm impulsionado a definição semântica do perfil

desde seu início:

um perfil deve fornecer mecanismos para especializar um metamodelo

de sua referente, de tal forma que a semântica especializada não

contradiz com a semântica do metamodelo de referência. Normalmente

o perfil de restrição define essas regras de boa formação, que são mais

consistentes com os especificados no metamodelo de referência;

deve ser possível a troca de perfis entre as ferramentas, juntamente

com os modelos a que tenham sido aplicados, usando o UML e o

Extensible Markup Language (XMI) como mecanismo de Intercâmbio.

Um perfil deve ser como um modelo UML de intercâmbio;

um perfil deve ser capaz de referenciar bibliotecas de domínio

específicas, onde esses elementos são pré-definidos;

deve ser possível determinar quais perfis estão sendo aplicados a um

determinado pacote. Isso é uma particularidade útil durante a troca de

modelo, de modo que um ambiente de importação possa interpretar um

modelo corretamente;

também deve definir uma extensão da UML que combina perfis e

bibliotecas do modelo (incluindo modelos de bibliotecas) em uma única

unidade lógica. No entanto, para maior clareza de definição e para

facilitar o intercâmbio dentro desta unidade lógica, deve ainda ser

possível manter as bibliotecas e os perfis distintos uns dos outros;

um perfil deve ser capaz de especializar a semântica dos elementos

padrões do metamodelo da UML. Por exemplo, em um modelo com

perfil “Java” uma generalização de classes deve ser capaz de ser

restrita a herança simples sem ter que atribuir explicitamente um

estereótipo “Java Classe” para toda instância da classe;

uma notação que define os estereótipos gráficos deve ser fornecida

como parte de um perfil;

a fim de satisfazer o requisito acima descrito, os perfis de UML devem

formar um mecanismo de extensão metamodelo que impõe certas

restrições sobre como o metamodelo pode ser modificado. O

metamodelo de referência é considerado como um modelo, que se

estende sem alteração por perfis. Portanto, não é permitido inserir

novas metaclasses na hierarquia da metaclasse ou modificar o padrão

de definição da UML. Tais restrições não se aplicam em um contexto

MOF onde qualquer metamodelo pode ser reformulado em qualquer

direção.

Os perfis podem ser dinamicamente aplicado ou retraído a partir de um

modelo. É possível fazer isso em um modelo existente para aplicar novos perfis, ou

para alterar um conjunto de perfis aplicados. Eles também podem ser

dinamicamente combinados, vários perfis serão aplicados ao mesmo tempo no

mesmo modelo. Esta combinação do perfil não pode ser prevista no momento da

definição do perfil mais sim no decorrer do processo (OMG, 2011b).

Um pacote perfil, e uma coleção que pode conter estereótipos, definições de

etiquetas e restrições, um subconjunto de elementos padrão UML, ou também novos

tipos de dados para facilitar a modelagem. Na Figura 11 pode-se visualizar um

pacote perfil referente à classe produto.

Figura 11 – Pacote Perfil da classe Produto.

Na Figura 12 foi criado o diagrama de perfil da classe produto, neste

diagrama foram usados elementos passíveis de serem incluídos em um perfil, como,

por exemplo, estereótipos e metaclasses, etc.

Para a metaclasse Class foi criado um elemento estereótipo produto que

referencia a classe Produto, este elemento é associado à metaclasse através de

uma associação do tipo Extend. Já a metaclasse atributo tem associado através dos

elementos estereótipos os atributos codproduto, nome e descrição, por fim a

metaclasse operação tem associado às operações listar, adicionar, excluir e

visualizar, todos esses elementos de estereótipo estão associados a sua respectiva

metaclasse através de uma associação do tipo Extend.

Figura 12 – Diagrama de Perfil da Classe Produto.

A partir da criação deste diagrama já se tem uma extensão do tipo XML e só

salvar este arquivo como .XML dentro da ferramenta que esta sendo usada para

modelar esse perfil no caso deste estudo foi utilizado a ferramenta Enterprise

Architect. No Quadro 3 mostrado a estrutura do pacote perfil da classe produto na

extensão XML.

<?xml version="1.0" encoding="windows-1252"?> <UMLProfile profiletype="uml2">

<Documentation id="338F8CBD-C" name="Produto" version="1.0" notes="Produto"/> <Content> <Stereotypes> <Stereotype name="Adicionar" notes="" cx="90" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1"

borderwidth="-1" hideicon="0"> <AppliesTo> <Apply type="Operation"> <Property name="isOrdered" value=""/> <Property name="isQuery" value="false"/> <Property name="isUnique" value=""/> <Property name="lower" value=""/> <Property name="upper" value=""/> </Apply> </AppliesTo> </Stereotype> <Stereotype name="CodProduto" notes="" cx="90" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1"

borderwidth="-1" hideicon="0"> <AppliesTo> <Apply type="Attribute"/> </AppliesTo> </Stereotype> <Stereotype name="Descricao" notes="" cx="90" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1"

borderwidth="-1" hideicon="0"> <AppliesTo> <Apply type="Attribute"/> </AppliesTo> </Stereotype>

<Stereotype name="Excluir" notes="" cx="90" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">

<AppliesTo> <Apply type="Operation"> <Property name="isOrdered" value=""/> <Property name="isQuery" value="false"/> <Property name="isUnique" value=""/> <Property name="lower" value=""/> <Property name="upper" value=""/> </Apply> </AppliesTo> </Stereotype> <Stereotype name="Listar" notes="" cx="90" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1"

borderwidth="-1" hideicon="0"> <AppliesTo> <Apply type="Operation"> <Property name="isOrdered" value=""/> <Property name="isQuery" value="false"/> <Property name="isUnique" value=""/> <Property name="lower" value=""/> <Property name="upper" value=""/> </Apply> </AppliesTo> </Stereotype> <Stereotype name="Nome" notes="" cx="90" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1"

borderwidth="-1" hideicon="0"> <AppliesTo> <Apply type="Attribute"/> </AppliesTo> </Stereotype> <Stereotype name="Produto" notes="" cx="90" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1"

borderwidth="-1" hideicon="0"> <AppliesTo> <Apply type="Class"> <Property name="isActive" value=""/> </Apply> </AppliesTo> </Stereotype> <Stereotype name="Visualizar" notes="" cx="90" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1"

borderwidth="-1" hideicon="0"> <AppliesTo> <Apply type="Operation"> <Property name="isOrdered" value=""/> <Property name="isQuery" value="false"/> <Property name="isUnique" value=""/> <Property name="lower" value=""/> <Property name="upper" value=""/> </Apply> </AppliesTo> </Stereotype> </Stereotypes> <TaggedValueTypes/> </Content>

</UMLProfile>

Quadro 3 – Pacote Perfil na extensão XML.

Esse pacote pode ser importado pra qualquer projeto a partir desta extensão

e esses elementos podem ser reaproveitados em vários outros modelos e situações.

Um perfil também serve para modelagem de negócios que consiste na definição de

um conjunto de estereótipos, que tem com objetivo demonstrar que a UML tem a

capacidade de modelar cenários de uma organização e não apenas sistema de

software (SBROCCO, 2011). Para isso se utiliza os estereótipos organization unit, que representa a unidade organizacional, work unit que representa uma unidade de

trabalho ou até mesmo uma entity que representa uma entidade.

Para um melhor entendimento da notação utilizada no diagrama de perfil foi

elaborado o Quadro 4 com a descrição de todos os componentes.

Tipos de caminho Notação Descrição

Profiles

Um perfil é uma especie de pacote

que estente um metamodelo de

referência. Um perfil é uma forma

restrita de um metamodelo que

deve sempre estar relacionado com

um metamodelo de referência.

Metaclasses

Uma classe derivou uma

associação que indica que ela foi

estendida por um ou mais

estereótipos. Um estereótipo é a

única espécie de metaclasse que

não pode ser estendida por um

estereótipo.

Estereótipos

Um estereótipo é uma espécie de

classe que se estende através de

extensões de classe. Assim como

uma classe, um estereótipo pode

ter propriedades. Quando um

estereótipo é aplicado a um

elemento de modelo, os valores

destas propriedades podem ser

referidas com valores definidos

neste pacotes.

Extensão

Uma extensão é usada para indicar

que as propriedades de uma

metaclasse são estendidas através

de um estereótipo. Esta associação

tem a capacidade de adicionar e

remover um estereótipo de uma

classe.

Quadro 4 – Componentes que fazem parte do diagrama de Tempo.

7 IMPLEMENTAÇÃO DO MAPA CONCEITUAL E DO WORKFLOW

Neste capítulo serão elaborados os mapas conceituais e o workflow dos

diagramas da UML, que visam auxiliar a maneira de elaborar e aplicar os diagramas

no desenvolvimento de softwares pelos engenhos e empresas. Serão apresentados

modelos que demonstram a relação entre os diagramas, de forma mais detalhada,

facilitando a compreensão dos conceitos e os relacionamentos de cada diagrama.

Para elaboração dos mapas conceituais, foi utilizada a ferramenta Cmap. Já

para a criação do workflow, utilizada a ferramenta BizAgi.

7.1 ESTRUTURA DOS DIAGRAMAS DA UML.

A UML é considerada para muitos engenheiros de software como uma

ferramenta essencial para o desenvolvimento de um software de qualidade. Grady

Booch (2005), um dos criadores da UML compara à construção de uma casa a

construção de um software, onde em cada etapa de uma casa, o arquiteto necessita

visualizar o projeto com perspectivas diferentes, a fim de esclarecer os detalhes.

Essa também e uma notação da UML que permite visualizar e detalhar a construção

de um software através de seus diagramas.

Como pode se observar, a Figura 13 apresenta a estrutura dos diagramas

onde é detalhado qual diagrama e dependente do outro. Pode se iniciar a

elaboração dessa estrutura através do diagrama de caso de uso, atividade, pacote

ou pelo diagrama de implantação. Note que a maioria dos diagramas tem

relacionamento com o diagrama de caso de uso, inclusive os diagramas que serão

detalhando neste estudo.

Para que a aprendizagem seja realmente significativa somente à estrutura

hierárquica dos diagramas da UML não é suficiente, visto que a mesma está

mostrando as relações dos diagramas e não o que é necessário fazer, passo a

passo, para a construção de cada diagrama, ou seja, a dinamicidade para o

processo de ensino e aprendizagem (TANAKA, 2009a).

Deste modo para completar a forma de elaborar e aplicar proposta neste

estudo foram desenvolvidos mapas conceituais e workflow dos diagramas propostos

nesta pesquisa.

Figura 13 - Estrutura dos Diagramas da UML 2.4.

7.2 MAPA CONCEITUAL E WORKFLOW DO DIAGRAMA DE ESTRUTURA

COMPOSTA.

O diagrama de estrutura composta destina-se à descrição dos

relacionamentos entre os elementos ele introduz um ponto de conexão entre os

elementos modelados, a quem pode se modelar interface. Esse diagrama também

pode ser usado para modelar colaborações. Uma colaboração descreve os objetos

que normalmente cooperam entre si para produzir uma tarefa ou um conjunto de

tarefas dentro de um sistema. Esse comportamento é a funcionalidade necessária

para se programar o sistema.

Os papéis de uma colaboração são interpretados por uma instância que

cooperam entre si para a conclusão de uma tarefa. Os relacionamentos dessas

instâncias são ligados por uma linha que liga uma instância a outra, chamado de

conectores (GUEDES 2009).

Uma ocorrência de colaboração representa a colaboração de uma classe

com a outra, de uma forma específica que envolve instâncias que executa papéis

específicos da colaboração, como um método. A Figura 14 apresenta o workflow da

elaboração do diagrama de estrutura composta e na Figura 15 é demonstrado de

forma mais detalhada a atividade de como montar o diagrama de estrutura

composta.

Figura 14 – Workflow para elaboração do Diagrama de Estrutura Composta.

Veja que na Figura 14 que para começar a elaboração do digrama de

estrutura composta iniciou-se com uma decisão, note que essa decisão tem dois

caminhos, um caminho iniciará pela compreensão dos conceitos relacionados onde

será exibido os mapas conceituais referente ao diagrama de estrutura composta, já o

outro caminho será inicializado por definir os colaboradores que farão parte do

conjunto entidade que cooperarão entre si.

Logo após, há duas atividades que acontecem simultaneamente: a

identificação dos papéis que são as instâncias que irão se cooperar entre si para a

conclusão da tarefa e a da verificação da ocorrência de uma colaboração que vai

verificar se a uma ocorrência de uma instância específica. Ao término das duas

atividades, inicia-se a elaboração do diagrama de estrutura composta. Para que o

diagrama seja sucinto e com qualidade no desenvolvimento, é necessária a

realização de refinamento contínuo. Isso e representado no workflow pelo fork

condicional, que acontece após a execução da atividade anterior, retornando ou não

para o início do workflow.

Figura 15 – Workflow da Atividade de Como Montar o Diagrama de Estrutura Composta.

A Figura 15 demonstra o workflow da atividade do diagrama de Estrutura

Composta, que visa facilitar a elaboração do Diagrama de Estrutura Composta.

Para se elaborar o diagrama de estrutura composta deve-se primeiramente

definir quais são os colaborados “classificadores” que serão modelados neste

diagrama. Em seguida, definiram-se quais papéis de uma colaboração será

interpretado pelas instâncias que cooperarão entre si para a conclusão da tarefa. Na

sequência verificar se a existência de uma instância que irá executar algum papel

específico dentro da colaboração, se existir será adicionada a instância do papel

específico, se não irá definir o tipo do relacionamento e a atividade estará pronta.

No workflow do diagrama de estrutura composta, foram identificadas quatro

atividades. Estas atividades estão descritas com o seu detalhamento nos Quadros 5

a 8.

Atividade “Definir Colaboradores”

A definição dos colaboradores é o primeiro passo para se definir quais

classes cooperarão entre si para a criação da estrutura. Neste ponto serão

definidos qual o relacionamento que uma classe terá com a outra.

O propósito principal de uma colaboração e explicar como o sistema irá

funcionar, portanto e fundamental que os colaboradores apresentem apenas os

aspectos extremamente necessários.

Metodologia

Entrevista

Questionamento

Simulação das interações das classes.

Produtos das Fases Anteriores

Ter Conhecimento do Negócio por intermédio da conversa com o

usuário.

Ter o diagrama de classe pronto, pois e fundamental saber qual classe

vai interagir com a outra.

Produtos Resultantes

Identificar as instâncias que cooperarão entre si para a realização da

tarefa.

Recursos

Analista de Sistema.

Usuário.

Computador.

Editor de Texto.

Software de modelagem “para visualização das classes”

Quadro 5 – Atividade “Definir Colaboradores”.

Atividade “Identificar Papéis”

Identificar papéis dentro de uma colaboração é definir qual instância

será utilizada, muitas vezes nem todas as características, nem todo o conteúdo

de uma instância participam das ligações de uma colaboração. Esses papéis

se encontram na estrutura interna de uma colaboração.

Um exemplo dessa estrutura interna pode se percebida na modelagem

da classe Abrir_Conta onde uma instância da classe Pessoa interpreta o

papel do cliente que colabora com uma instância da classe Conta_Comum,

que interpreta o papel da conta.

Metodologia




usuário.


Demonstrar a estrutura interna de uma colaboração

Recursos


Usuário.

Computador.

Editor de Texto.


Quadro 6 – Atividade “Identificar Papéis”.

Atividade “Verificar Ocorrência de Colaboração”

Nesta atividade irá se verificar se a colaboração vai apresentar uma

situação específica que envolva alguma classe ou instância que executará um

papel específico dentro desta colaboração.

Uma ocorrência de colaboração tem o foco de eliminar a redundância

de uma instância da colaboração, se uma ocorrência de colaboração já estiver

sido relacionado a um classificador, essa colaboração vai representar a

atividade, no qual o método já estará definido na classe, pode se representar

essa ocorrência através do relacionamento de dependência.

Metodologia


Definição dos métodos nas classes.



usuário.


Demonstrar uma situação específica de um papel.

Recursos


Usuário.

Computador.

Editor de Texto.


Quadro 7 – Atividade “Verificar Ocorrência de Colaboração”.

Elaborar “Diagrama de Estrutura Composta”

O diagrama de estrutura composta e composto pela colaboração de

um conjunto de elementos de cooperam entre si. Esses elementos são

formados por papéis e ou por alguma ocorrência de uma colaboração

específica, esses papéis ou ocorrência se comunicam através de

relacionamentos. Também e utilizado conectores como, por exemplo, o

conector Represents que indica uma colaboração utilizada por um

classificador.

Na estrutura composta também se utiliza porta e interfaces, uma porta

é o elemento usado para especificar um ponto de interação entre uma classe.

Uma porta pode estar associada a mais de uma interface. As interfaces podem

ser do tipo requerida ou fornecida.

Interface requerida refere-se ás operações que o classificador

espera do ambiente que esta inserido.

Interface fornecida refere-se ás operações que o classificador

oferece a esse ambiente.

A Figura 4 mostra um exemplo de colaboração da classe Venda do

sistema iTrade, esta inserido na estrutura interna da classe Venda, as classes

fornecedores, fabricante, estoque e produto que são as entidades que

cooperarão entre si.

Já na Figura 5 mostra o exemplo de uma colaboração composta por

partes que representa uma colaboração simplesmente conectada por classes.

Metodologia




usuário.

Ter as classes definidas.

Ter o relacionamento das classes.


Diagrama de estrutura composta que representa a arquitetura de

tempo de execução, e os relacionamentos entre os elementos participantes.

Recursos


Usuário.

Computador.

Editor de Texto.

Software de diagramação (ex: Enterprise Architect)

Quadro 8 – Elaborar “Diagrama de Estrutura Composta”.

Na Figura 16 pode-se observar o mapa conceitual do diagrama de estrutura

composta, na qual serão apresentados os conceitos que foram envolvidos para o

desenvolvimento deste diagrama.

Figura 16 – Mapa Conceitual do Diagrama de Estrutura Composta.

7.3 MAPA CONCEITUAL E WORKFLOW DO DIAGRAMA DE VISÃO GERAL

Um diagrama de visão geral tem o objetivo de apresentar de uma forma

geral, o fluxo de controle utilizado em sistema ou processo de negocio, deste modo

cada nó ou atividade dentro desse diagrama pode representar outro diagrama de

interação (SBROCCO, 2011).

Ele é uma variação do diagrama de atividade, esse diagrama permite

captura uma perspectiva estática dos fluxos de interação entre os componentes de

um sistema geral. Este diagrama utiliza quadros no lugar de nós de decisão, embora

como no diagrama de atividade utilize símbolos de nós para indicar o inicio e o

término do processo.

Basicamente esse diagrama utiliza dois tipos de quadro, o quadro de

interação que pode ser qualquer diagrama da UML (diagrama de sequência) e os

quadros de ocorrência de interação que normalmente faz uma referência a um

diagrama de interação.

Na Figura 17 é demonstrado o workflow para a criação do diagrama de visão

geral de interação

Figura 17 – Workflow do Diagrama de Visão Geral.

Veja que na Figura 17 que para começar a elaboração do digrama de visão

geral iniciou-se com uma decisão, note que essa decisão tem dois caminhos, um

caminho iniciará pela compreensão dos conceitos relacionados onde será exibido o

mapa conceitual referente ao diagrama de visão geral, já o outro caminho será

inicializado por “Estabelecer o Foco no Diagrama”. Logo após, há duas atividades

que acontecem simultaneamente à atividade de “Definir Quadros de Interação” onde

poderá contém qualquer diagrama da UML e a atividade de “Definir Quadros de

ocorrência de Interação” que normalmente faz referência a um diagrama de

interação, mas não vai apresentar o seu detalhamento.

Para que o diagrama seja sucinto e com qualidade no desenvolvimento, é

necessária a realização de refinamento contínuo. Isso e representado no workflow

pelo fork condicional, que acontece após a execução da atividade anterior,

retornando ou não para o início do workflow.

Figura 18 – Workflow da Atividade Criar o Diagrama de Visão Geral.

A Figura 18 demonstra o workflow da atividade do diagrama de Visão Geral,

que visa facilitar a elaboração do mesmo.

Para a elaboração deste diagrama deve-se primeiramente definir por onde

começará a interação (por qual caso de uso), em seguida serão separados todos os

outros quadros de interação seja ele de ocorrência de interação ou só de interação.

Logo após a definição e a separação das interações, será definida se o diagrama

começará por um quadro de interação ou um quadro de ocorrência de interação

visto que qualquer um dos dois quadros pode estar no começo, no meio ou no fim

do diagrama. Após essa definição será criado os nós de decisão, por fim será

definida qual interação fechará o processo, se por acaso o diagrama ter ficado muito

extenso e com pouca objetividade, o diagrama poderá ser refinado se isso acontecer

o processo voltará ao seu início.

No workflow do diagrama visão geral, foram identificadas quadro atividades.

Estas atividades estão descritas com o seu detalhamento nos Quadros 9 a 12.

Atividade “Estabelecer Foco do Diagrama”

Na atividade “Estabelecer Foco do Diagrama deve-se definir para qual

lugar o diagrama de visão geral será modelado, antes que as outras atividades

do workflow sejam executadas.

Deve-se levar em conta que o diagrama de visão geral pode ser

modelado a partir de um caso de uso ou de vários casos de uso que vão se

interagir entre eles dentro do sistema.

Ao definir pela elaboração do diagrama de visão geral, modela-se a

sequência lógica dos acontecimentos dentro do caso de uso, que são

processos que estão interligados em um processo geral.

Metodologia

Questionamento

Simulação das interações dentro de um caso de uso ou de um conjunto

de casos de uso.


Ter conhecimento do negócio por intermédio da conversa com o

usuário.

Ter o diagrama de caso de uso definido, pois e fundamental saber qual

são interações dentro do caso de uso específico.


Identificar os processos que são interligados entre sim.

Recursos


Usuário.

Computador.

Editor de Texto.

Software de modelagem “para visualização das casos de uso”

Quadro 9 – Atividade “Estabelecer Foco do Diagrama”.

Atividade “Definir Quadros de Interação”

Define-se o processo mais importante dentro desta interação, neste

quadro pode conter qualquer diagrama da UML. No exemplo exposto neste

estudo foi inserido dentro deste quadro um diagrama de sequência que pode

ser visto na Figura 7, onde é mostrada a sequencia que o sistema deve fazer

para se adicionar um produto ao carrinho de compra. O quadro de interação

pode ocorrer no inicio no meio ou no fim do diagrama.

Metodologia

Conhecimento do negócio



usuário.

Ter os diagramas de sequência prontos, pois e fundamental saber qual

são interações dentro do caso de uso específico.

Diagrama de Caso de Uso.

Especificações de Caso de Uso.


Identificar o processo mais importante dentro desta interação.

Recursos


Usuário.

Computador.

Editor de Texto.

Software de modelagem.

Quadro 10 – Atividade “Definir Quadro de Interação”

Atividade “Definir Quadro de ocorrência de Interação”

Deve definir os processos que farão parte do diagrama que não serão

detalhados. Esses quadros de ocorrência de interação também referenciam a

diagramas de sequência. No entanto eles só serão referenciados para não

deixar o diagrama muito extenso.

No exemplo exposto na Figura 7 a quatro quadros de ocorrência de

interação, que se interage com o quadro de interação, que contém em seu

interior um diagrama de sequência.

Metodologia




usuário.




Identificar os outros processos que farão parte do diagrama e não terão

os seus quadros detalhados.

Recursos


Usuário.

Computador.

Editor de Texto.


Quadro 11 – Atividade “Definir Ocorrência de Interação”

Elaborar Diagrama de Visão Geral

O diagrama o de visão geral tem o objetivo de visualizar o controle de

fluxo, para o controle desse fluxo esse o mesmo utiliza quadros de interações

no lugar de nós de ação que é utilizado no diagrama de atividade. A estrutura

deste diagrama e composta pelos quadros de interação que representa

processo mais importante dentro da interação e pelos quadros de ocorrência

de interação que representa as interações secundarias dentro do processo. Na

Figura 7 a foi elaborado o diagrama de visão geral do processo de adicionar

produto ao carrinho de compra.

Metodologia




usuário.




Diagrama de Visão geral que fornece a visão geral do fluxo de controle.

Recursos


Usuário.

Computador.

Editor de Texto.


Quadro 12– Elaborar “Diagrama de Visão Geral”

Na Figura 19 pode-se observar o mapa conceitual do diagrama de estrutura

composta, na qual serão apresentados os conceitos que foram envolvidos para o

desenvolvimento deste diagrama.

Figura 19 – Mapa Conceitual do Diagrama de Visão Geral.

7.4 MAPA CONCEITUAL E WORKFLOW DO DIAGRAMA DE TEMPO.

O diagrama de Tempo ou de Temporização tem como foco as mudanças de

estado de um objeto ao longo do tempo. A cronometragem deste diagrama foca na

condição de mudança dentro de uma linha de vida, ao longo de um eixo.

Esse diagrama descreve o comportamento dos classificadores individuais e

os classificadores de interações, focando a atenção nos eventos que causam

mudança na condição modelada na linha de vida.

Este diagrama de suma importância na modelagem de aplicações em tempo

real, onde o tempo em que um objeto executa algo é muito importante, como em

uma transação de cartão de crédito que será utilizada como exemplo neste estudo.

Na Figura 20 é demonstrado o workflow para a criação do Tempo

Figura 20 – Workflow do Diagrama de Tempo.

A Figura 20 começa a elaboração do digrama de tempo iniciou com uma

decisão, note que essa decisão tem dois caminhos, um caminho iniciará pela

compreensão dos conceitos relacionados onde será exibido o mapa conceitual

referente ao diagrama de tempo, já o outro caminho será inicializado por

“Estabelecer o Foco no Diagrama”. Logo após, há duas atividades que acontecem

simultaneamente à atividade de “Definir Estado” onde serão apresentados todos os

estados que irá conter no diagrama e o de “Definir Eventos” que conterá todos os

eventos do diagrama. Após o a definição destas duas tarefas, irá acontecer a tarefa

de “Definir o Tempo de Execução de cada Transição” onde será definida qual o

tempo que cada evento demorará a acontecer, após esses acontecimentos o

diagrama poderá ser criado.





Figura 21 – Workflow da Atividade Elaborar Diagrama de Tempo.

A Figura 21 demonstra o workflow da atividade do diagrama de Tempo, que

visa facilitar a elaboração do mesmo.

Para a elaboração deste diagrama deve-se primeiramente definir as linhas

de estado que ira conter neste diagrama, em seguida deve verificar se neste

diagrama irá conter com mais de uma linha de estado, se isso ocorrer, deve definir

em que ponto do diagrama haverá a interação entre as duas linhas de estado, essa

interação acontece através de uma seta (mensagens). Logo após essas definições

serão definidos quais estados cada linha de estado conterá, como também será

definidos quais eventos irão ocorrer em cada transição de estado. Finalmente a

atividade de “Definir o Tempo de Duração de cada Transição” irá definir quanto

tempo levará para que cada evento aconteça.

No workflow do diagrama tempo, foram identificadas cinco atividades. Estas

atividades estão descritas com o seu detalhamento nos Quadros 13 a 17.


Na atividade “Estabelecer Foco do Diagrama deve-se definir quais caso

de uso o tempo de execução de um de seus objetos será levado em conta no

decorrer da realização da funcionalidade.

Este diagrama pode ser modelado de duas formas, uma forma e

conhecida como concisa que é a forma mais simples deste diagrama que e

chamada de linha de vida de valor esta forma pode ser vista na Figura 8 deste

estudo. Outra forma e considerada mais robusta onde as estadas são

apresentadas em forma de gráficos, chamada linha de vida de estado, esta

forma pode ser vista na Figura 10.

Esse diagrama foca se nas condições que a mudança do objeto na

linha de vida de um eixo de tempo descreve o comportamento de seus

classificadores e suas interações. O termo linha de vida descreve o caminho

percorrido por um objeto durante um determinado tempo.

Metodologia


de casos de uso.



usuário.

Ter o diagrama de caso de uso definido, pois e fundamental saber

quais casos de uso o tempo tem influência no seu funcionamento


Identificar objetos o que o tempo influência no seu funcionamento.

Recursos


Usuário.

Computador.

Editor de Texto.


Quadro 13 – Atividade “Estabelecer Foco do Diagrama”

Atividade “Definir Estados”

Nesta atividade serão definidos os estados que fará parte deste

diagrama, a definição de estado e semelhante às definições usadas no

diagrama de máquina de estado. Um estado representa a situação em que um

objeto se encontra em determinado momento durante o período em que este

estado participa do processo.

Um estado pode demonstrar a espera por uma ocorrência de um

evento, também pode demonstrar a reação a um estímulo ou até a satisfação

de alguma condição no decorrer do processo.

Metodologia


de casos de uso.



usuário.


quais casos de uso o tempo tem influência no seu funcionamento.


Identificar os estados de um objeto dentro do processo.

Recursos


Usuário.

Computador.

Editor de Texto.

Software de modelagem

Quadro 14 – Atividade “Definir Estados”.

Atividade “Definir Eventos”

Nesta atividade serão definidos todos os eventos (transição) que farão

parte deste diagrama, a definição de evento e semelhante às definições usadas

no diagrama de máquina de estado. Um evento representa a causa da

mudança no estado de um objeto, gerando um novo estado. Na descrição de

um evento pode tanto conter uma ordem para a realização de alguma tarefa ou

simplesmente uma informação da ocorrência de um evento.

Metodologia


de casos de uso.



usuário.




Identificar os eventos que causaram a mudança no estado de um

objeto.

Recursos


Usuário.

Computador.

Editor de Texto.


Quadro 15 – Atividade “Definir Eventos”.

Atividade “Definir Tempo de Execução de cada Transição”

Nesta atividade será definido o tempo de execução de cada transição

de um estado de um objeto para um estado novo. A descrição deste tempo irá

aparece na frente do evento. Na Figura 10 mostra que toda transição tem o seu

tempo estimado. Esse tempo é muito importe em sistema em tempo real com

uma transação de cartão de crédito.

Metodologia


de casos de uso.



usuário.




Identificar o tempo de cada evento na mudança no estado de um objeto

para outro.

Recursos


Usuário.

Computador.

Editor de Texto.


Quadro 16 – Atividade “Definir Tempo de Execução de cada Transição”.

“Elaborar Diagrama de Tempo”

O digrama de tempo ou temporalização como e chamado tem como

objetivo o enfoque na mudança de estado de um objeto ao longo do tempo.

Isso permite especificar em um processo um fator em que o tempo e crítico, por

exemplo, uma a compra de um produto em uma loja virtual onde o tempo de

resposta referente ao pagamento que o cliente fez usando um cartão de crédito

e determinante para a liberação do produto. Na Figura 10 foi elaborado o

diagrama de tempo “Gerenciar Cartão de Crédito” na sua forma mais robusta

onde e detalhado todos os estados e eventos que podem ocorrer neste

processo.

Metodologia


de casos de uso.



usuário.




Mostrar o comportamento dos objetos e sua interação em uma escala

de tempo.

Recursos


Usuário.

Computador.

Editor de Texto.


Quadro 17 – Elaborar Diagrama de Tempo.

Na Figura 22 pode-se observar o mapa conceitual do diagrama tempo, na

qual serão apresentados os conceitos que foram envolvidos para o desenvolvimento

deste diagrama.

Figura 22 – Mapa Conceitual do Diagrama de Tempo.

7.5 MAPA CONCEITUAL E WORKFLOW DO DIAGRAMA DE PERFIL

Um perfil é uma espécie de pacote que estende um metamodelo de

referencia, um perfil define os mecanismos usados para adaptar um metamodelo

existente. Isto inclui a capacidade de adaptar o metamodelo UML a outras

plataformas ou domínio específicos tais com J2EE ou .NET. Um perfil é uma forma

restrita de um metamodelo que deve sempre estar relacionado com um metamodelo

de referência.

O uso de perfis permite aos usuários criarem dialetos da UML, de forma que

os mesmos estejam adequados às tecnologias de desenvolvimento adotadas por

uma determinada empresa ou mesmo à sua área de negocio. Além disso, a

utilização de perfis permitirá a adaptação da UML ao surgimento de novas

tecnologias, sem a necessidade de se alterar o núcleo da linguagem (GUEDES,

2009).

Basicamente esse diagrama usa duas notações básicas que são as

metaclasses e os estereótipos, uma metaclasse é uma classe que se derivou a uma

associação que indica que essa classe foi estendida por um ou mais estereótipos, já

um estereótipo é uma espécie de classe que se estende através de extensões de

uma classe.

Na Figura 23 é demonstrado o workflow para a criação do diagrama de visão

geral de interação

Figura 23 – Workflow do Diagrama de Perfil.

Veja que na Figura 23 que para começar a elaboração do diagrama (pacote)

de perfil iniciou-se com uma decisão, note que essa decisão tem dois caminhos, um

caminho iniciará pela compreensão dos conceitos referentes onde será exibido o

mapa conceitual do diagrama de perfil, já o outro caminho será inicializado por

“Estabelecer o Foco do Diagrama” onde será definida qual classe será elaborado o

pacote de perfil. Logo após, há duas atividades que acontecem simultaneamente à

atividade de “Definir Metaclasse” onde será definido a classe, atributos e operações

e o de “Definir Estereótipos” que conterá o nome da classe, todos os atributos e

operações que essa classe vai conter, após essas definições será criado o diagrama

de perfil da referida classe.





Figura 24 – Workflow da Atividade do Diagrama de Perfil.

A Figura 24 demonstra o workflow da atividade do diagrama de Perfil, que

visa facilitar a elaboração do mesmo.

Para a elaboração deste diagrama deve-se primeiramente definir quais as

classes do sistema será transformado em um pacote perfil, sempre lembrando que

para não ficar criando perfis que não serão utilizados em projetos futuros o analista

deve procurar ser o mais objetivo possível na criação de um pacote perfil, em

seguida deve se definir quais metaclasse serão criadas neste pacote, uma

metaclasse pode ser uma classe, um atributo ou método (operações). Logo após

essas definições serão definidos os estereótipos de cada metaclasse, um

estereótipo representa as propriedades de uma metaclasse, em seguida será

definido que tipo de relacionamento estas metaclasses terá com os seus respectivos

estereótipos. Feito essa definições a próxima atividade a ser executada e a

realização das ligações entre as metaclasse e os estereótipos, por fim tem um nó de

decisão onde podem ser refinados os estereótipos.

No workflow do diagrama perfil, foram identificadas quatro atividades. Estas

atividades estão descritas com o seu detalhamento nos Quadros 18 a 21.


Na atividade “Estabelecer Foco do Diagrama” deve-se definir a partir

de que classes serão criadas os pacotes perfis para que sejam utilizados em

outros projetos. Deve se levar em conta que esses pacotes poderão ser

adaptados para outra linguagem. Por isso deve ser criados pacotes só das

classes que realmente serão utilizadas no futuro.

O uso de perfis permite aos usuários criarem dialetos da UML, de

forma que os mesmos estejam adequados às tecnologias de desenvolvimento

adotadas por uma determinada empresa ou mesmo à sua área de negocio. Na

Figura 12 pode ser observada a criação deste pacote usando a classe produto.

Metodologia

Conhecimento do Negócio.


Ter conhecimento do negócio da empresa para poder definir se a

classe escolhida poderá ser reaproveitada no futuro.

Ter o diagrama de classe definido, pois e fundamental saber quais

atributos e métodos serão utilizados para criar o perfil.


Pacote perfis que poderão ser reutilizados no futuro.

Recursos


Computador.

Editor de Texto.


Quadro 18 – Atividade “Estabelecer Foco do Diagrama”

Atividade “Definir Metaclasses”

Nesta atividade serão definidas as metaclasses que serão utilizadas,

uma metaclasse pode ser uma classe, um atributo ou uma operação, um

pacote de perfil pode ter todas essa metaclasse no mesmo pacote. Uma classe

derivou uma associação que indica que ela foi estendida por um ou mais

estereótipos. Um estereótipo é a única espécie de metaclasse que não pode

ser estendida por um ou mais estereótipos. Na Figura 12 pode se observar que

foram definidas no diagrama de perfil produto as metaclasse classe, atributos e

operações.

Metodologia

Ter conhecimento do negócio.


Ter o diagrama de classe definido, pois e essencial saber se aquela

classe terá atributos e métodos, pois em alguns casos as classes podem ter

somente métodos ou atributos.


Identificar as metaclasses que farão parte do pacote perfil.

Recursos


Computador.

Editor de Texto.


Quadro 19 – Atividade “Definir Metamodelos”.

Atividade “Definir Estereótipos”

Nesta atividade serão definidos todos os estereótipos que farão parte

deste diagrama, um estereótipo é uma espécie de classe que se estende

através de extensões de classe. Assim como uma classe, um estereótipo pode

ter propriedades.

Quando um estereótipo é aplicado a um elemento de modelo, os

valores destas propriedades podem ser referidos com valores definidos neste

pacote. Note que na Figura 12 que os estereótipos assumem os valores que

são associados às metaclasse através da associação Extend, por exemplo, a

metaclasse atributo tem nela associada dois estereótipos com valores que são

eles codproduto e descrição.

Metodologia

Ter Conhecimento do Negócio.


Ter o diagrama de classe definido, pois e essencial saber quais os

atributos e métodos que as classes escolhidas para a criação dos pacotes

perfis contêm.


Identificar os estereótipos que farão parte do pacote perfil desejado.

Recursos


Computador.

Editor de Texto.


Quadro 20 – Atividade “Definir Estereótipos”.

“Elaborar o Diagrama de Perfil”

O digrama ou pacote de perfil como e conhecido tem como objetivo

fornecer mecanismos para reutilizar um metamodelo de sua referência. O uso

de perfis permite que aos usuários criem dialetos que possam ser utilizada em

novas tecnologias ou em projetos futuros como uma forma de diminuir o tempo

no desenvolvimento do projeto. Além disso, a utilização de perfis permitirá a

adaptação da UML ao surgimento de novas tecnologias, sem a necessidade de

se alterar o núcleo da linguagem.

Metodologia

Ter Conhecimento do Negócio.


Ter conhecimento do negócio da empresa para poder definir se a

classe escolhida poderá ser reaproveitada no futuro.

Ter o diagrama de classe definido, pois e fundamental saber quais

atributos e métodos serão utilizados para criar o perfil


Criar novos modelos perfis para serem utilizados em projetos futuros.

Recursos


Computador.

Editor de Texto.


Quadro 21 – Elaborar Diagrama de Perfil.

Na Figura 25 pode-se observar o mapa conceitual do diagrama de perfil, na

qual serão apresentados os conceitos que foram envolvidos para o desenvolvimento

deste diagrama.

Figura 25 – Mapa Conceitual do Diagrama de Perfil.

8 CONCLUSÕES E TRABALHOS FUTUROS

Os resultados obtidos deste trabalho foi de grande valia para a

implementação dos diagramas no desenvolvimento de software, visto que esses

diagramas ainda não são muito utilizados no mercado, esses diagramas são novos

em relação a outros diagramas que compõe a UML, e muitos analistas ainda não

conhecem a verdadeira importância de cada para o bom desenvolvimento de

projetos de software. Por serem novos esses diagramas também não possui tantos

exemplos de utilização e não contém um vasto acervo bibliográfico que ajude o seu

entendimento.

Este trabalho apresentou uma proposta prática para utilização dos mesmos,

utilizando um exemplo na implantação de um sistema, sempre visando mostrar

exemplos que mais se encaixavam na estrutura proposta por cada diagrama,

também utilizou se das ferramentas de workflow e mapas conceitos para ajudar na

visualização de seus conceitos e atividades facilitando assim a sua compreensão.

O resultado deste estudo mostra que os novos diagramas da UML 2.4 são

de suma importância para bom andamento do desenvolvimento de um sistema,

esses diagramas oferecem estruturas que facilitam muito no desenvolvimento de

aplicativos em tempos real, também gera código que podem ser reaproveitados em

outras linguagens diminuindo o tempo desenvolvimento, possibilitando também a

interação entre diagramas possibilitando assim uma visualização mais ampla do

funcionamento do sistema.

Já o uso das ferramentas de workflows e mapas conceituais possibilita um

melhor entendimento dos conceitos e aplicações por parte do desenvolvedor,

permitindo estabelecer a ordem de execução entre as atividades e as condições que

cada atividade precisa para ser inicializada. Essas ferramentas também permitem ao

leitor visualizar os passos a serem seguidos para a elaboração dos diagramas da

UML.

Para cada diagrama proposto neste estudo foi desenvolvido exemplos a

partir das funcionalidades que melhor se encaixava nos seus respectivos diagramas

esses exemplos podem ser visto ao longo deste texto. Para cada diagrama também

foi elaborado mapas conceituais e workflows, os mapas conceituais foram

elaborados como forma de representar seus conceitos e descrições de forma visual,

já os workflows demonstra o fluxo de atividade de cada diagrama.

Como possíveis trabalhos futuros, pode-se apontar a implementação deste

estudo na educação a distancia (EAD), pois a interação que essas ferramentas

oferecem é de grande valor na compreensão do problema. Os mapas conceituais e

workflows poderão ser utilizados para a apresentação de projetos de software, pois

sua dinâmica de mostrar as interações das atividades ajudará o cliente entender o

funcionamento do sistema.

REFERÊNCIAS

AUSUBEL, David et al. Psicologia educacional. Rio de Janeiro: Interamericano, 1980.

BARROS, Rodolfo Miranda de. Um estudo sobre o poder das metáforas e dos recursos multimídia no processo de ensino e aprendizagem de cálculo diferencial e integral. 2008. 142 f. Tese (Doutorado em Engenharia Elétrica) - Universidade Estadual de Campinas, Campinas, 2008.

BIZAGI. Bizagi process modeler. Disponível em: <http//www.bizagi.com>. Acesso em: 31 out. 2011.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Rio de Janeiro: Elsevier, 2005.

CMAP. CMAP tools. Disponível em: <http://cmap.ihmc.us>. Acesso em: 01 set. 2011.

ENTERPRISE ARCHITECT. UML development tool: versão 9.1. Victoria: Sparx Systems, 2012.

GUEDES, Gilleanes T. A. UML 2: uma abordagem prática. São Paulo: Novatec, 2009.

JOOSTEN, Stef; BRINKKEMPER, Sjaak. Fundamental concepts for workflow automation in pratice. 12 mar. 1995. Disponível em: <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.6440>. Acesso em: 20 ago. 2011.

Lima, Adilson Da Silva. UML 2.3: do requisito à solução. São Paulo: Érica, 2011.

MOREIRA, Marco Antonio; CABALLERO SAHELICES, Concesa; RODRÍGUEZ PALMERO, Maria Luz. Aprendizaje significativo: interacción personal, progresividad y lenguaje. Burgos: Universidad de Burgos.

OMG. Unified modeling language: infrastructure. 2011a. Disponível em: <http://www.omg.org/spec/uml/2.4/infrastructure>. Acesso em: 28 jun. 2011a.

OMG. Unified modeling language: superstructure. 2011b. Disponível em: <http://www.omg.org/spec/uml/2.4/superstructure>. Acesso em: 28 jun. 2011b.

RATIONAL SOFTWARE CORPORATION. Rational unified process: Versão 7.1.1. New York: IBM Corporation, 2007.

SBROCCO, José Henrique Teixeira de Carvalho. UML 2.3: teoria e prática. São Paulo: Érica, 2011.

TANAKA, Simone Sawasaki. O poder da tecnologia de workflow e dos mapas conceituais no processo de ensino e aprendizagem da UML. Disponível em: <http://rio.br/fess/artigos/artigos fees10/a2.pdf>. Acesso em: 20 ago. 2011a.

TANAKA, Simone Sawasaki. O poder da tecnologia de Workflow e dos mapas conceituais no processo de ensino e aprendizagem da UML. 2011b. 90 f. Dissertação (Mestrado em Ciência da Computação) - Universidade Estadual de Londrina, Londrina, 2011.

TELECKEN, Tiago. Definição de processo de Workflow. Disponível em: <www.arquivar.com.br/espaco_profissional/...workflow.../file>. Acesso em: 20 ago. 2011.

VARGAS, Thânia Clair De Souza. A história de UML e seus diagramas. Disponível em: <http://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/artigo.tcc.pdf>. Acesso em: 20 ago. 2011.

Documents

DEPARTAMENTO DE COMPUTAÇÃO CURSO DE PÓS …web.unifil.br/pergamum/vinculos/000006/00000679..pdf · OLIVEIRA, Eder Diego. Elaboração e Aplicabilidade de Mapas Conceituais e Workflow