Post on 15-Dec-2018
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
EDER DIEGO DE OLIVEIRA
ELABORAÇÃO E APLICABILIDADE DE MAPAS CONCEITUAIS E WORKFLOW NOS DIAGRAMAS DA UML 2.4 EM UM ESTUDO DE CASO
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
EDER DIEGO DE OLIVEIRA
ELABORAÇÃO E APLICABILIDADE DE MAPAS CONCEITUAIS E WORKFLOW NOS DIAGRAMAS DA UML 2.4 EM UM ESTUDO DE CASO
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
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.
Produtos Resultantes
Demonstrar a estrutura interna de uma colaboração
Recursos
Analista de Sistema.
Usuário.
Computador.
Editor de Texto.
Software de modelagem “para visualização das classes”
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
Simulação das interações das classes.
Definição dos métodos nas classes.
Produtos das Fases Anteriores
Ter Conhecimento do Negócio por intermédio da conversa com o
usuário.
Produtos Resultantes
Demonstrar uma situação específica de um papel.
Recursos
Analista de Sistema.
Usuário.
Computador.
Editor de Texto.
Software de modelagem “para visualização das classes”
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
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 as classes definidas.
Ter o relacionamento das classes.
Produtos Resultantes
Diagrama de estrutura composta que representa a arquitetura de
tempo de execução, e os relacionamentos entre os elementos participantes.
Recursos
Analista de Sistema.
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.
Produtos das Fases Anteriores
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.
Produtos Resultantes
Identificar os processos que são interligados entre sim.
Recursos
Analista de Sistema.
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
Produtos das Fases Anteriores
Ter conhecimento do negócio por intermédio da conversa com o
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.
Produtos Resultantes
Identificar o processo mais importante dentro desta interação.
Recursos
Analista de Sistema.
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
Conhecimento do negócio
Produtos das Fases Anteriores
Ter conhecimento do negócio por intermédio da conversa com o
usuário.
Diagrama de Caso de Uso.
Especificações de Caso de Uso.
Produtos Resultantes
Identificar os outros processos que farão parte do diagrama e não terão
os seus quadros detalhados.
Recursos
Analista de Sistema.
Usuário.
Computador.
Editor de Texto.
Software de modelagem.
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
Conhecimento do negócio
Produtos das Fases Anteriores
Ter conhecimento do negócio por intermédio da conversa com o
usuário.
Diagrama de Caso de Uso.
Especificações de Caso de Uso.
Produtos Resultantes
Diagrama de Visão geral que fornece a visão geral do fluxo de controle.
Recursos
Analista de Sistema.
Usuário.
Computador.
Editor de Texto.
Software de modelagem.
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.
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 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.
Atividade “Estabelecer Foco do Diagrama”
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
Simulação das interações dentro de um caso de uso ou de um conjunto
de casos de uso.
Produtos das Fases Anteriores
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
quais casos de uso o tempo tem influência no seu funcionamento
Produtos Resultantes
Identificar objetos o que o tempo influência no seu funcionamento.
Recursos
Analista de Sistema.
Usuário.
Computador.
Editor de Texto.
Software de modelagem.
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
Simulação das interações dentro de um caso de uso ou de um conjunto
de casos de uso.
Produtos das Fases Anteriores
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
quais casos de uso o tempo tem influência no seu funcionamento.
Produtos Resultantes
Identificar os estados de um objeto dentro do processo.
Recursos
Analista de Sistema.
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
Simulação das interações dentro de um caso de uso ou de um conjunto
de casos de uso.
Produtos das Fases Anteriores
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
quais casos de uso o tempo tem influência no seu funcionamento.
Produtos Resultantes
Identificar os eventos que causaram a mudança no estado de um
objeto.
Recursos
Analista de Sistema.
Usuário.
Computador.
Editor de Texto.
Software de modelagem
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
Simulação das interações dentro de um caso de uso ou de um conjunto
de casos de uso.
Produtos das Fases Anteriores
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
quais casos de uso o tempo tem influência no seu funcionamento.
Produtos Resultantes
Identificar o tempo de cada evento na mudança no estado de um objeto
para outro.
Recursos
Analista de Sistema.
Usuário.
Computador.
Editor de Texto.
Software de modelagem
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
Simulação das interações dentro de um caso de uso ou de um conjunto
de casos de uso.
Produtos das Fases Anteriores
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
quais casos de uso o tempo tem influência no seu funcionamento.
Produtos Resultantes
Mostrar o comportamento dos objetos e sua interação em uma escala
de tempo.
Recursos
Analista de Sistema.
Usuário.
Computador.
Editor de Texto.
Software de modelagem
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.
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 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.
Atividade “Estabelecer Foco do Diagrama”
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.
Produtos das Fases Anteriores
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.
Produtos Resultantes
Pacote perfis que poderão ser reutilizados no futuro.
Recursos
Analista de Sistema.
Computador.
Editor de Texto.
Software de modelagem.
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.
Produtos das Fases Anteriores
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.
Produtos Resultantes
Identificar as metaclasses que farão parte do pacote perfil.
Recursos
Analista de Sistema.
Computador.
Editor de Texto.
Software de modelagem
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.
Produtos das Fases Anteriores
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.
Produtos Resultantes
Identificar os estereótipos que farão parte do pacote perfil desejado.
Recursos
Analista de Sistema.
Computador.
Editor de Texto.
Software de modelagem
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.
Produtos das Fases Anteriores
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
Produtos Resultantes
Criar novos modelos perfis para serem utilizados em projetos futuros.
Recursos
Analista de Sistema.
Computador.
Editor de Texto.
Software de modelagem
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.