análise orientada a objetos ii - uniasselvi

2015

Análise OrientAdA A ObjetOs ii

Profa. Simone Cristina Aléssio

Copyright © UNIASSELVI 2015

Elaboração:

Profa. Simone Cristina Aléssio

Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.

005.1A372a Aléssio, Simone Cristina Análise orientada a objetos II/ Simone Cristina Aléssio.

Indaial : UNIASSELVI, 2015.

156 p. : il. ISBN 978-85-7830-934-3

1. Programação Orientada a Objetos. I. Centro Universitário Leonardo Da Vinci.

III

ApresentAçãO

Prezado(a) acadêmico(a)! Seja bem-vindo(a) ao mundo da Programação Orientada a Objetos.

Neste universo você vai se deparar com termos como atributos, métodos, abstração, encapsulamento, classes, hierarquia das classes, processo unificado, entre outros, que compõem o material de estudo desta disciplina e, por consequência, o dia a dia de um analista, desenvolvedor, programador, ou seja, o profissional da programação.

Este caderno pressupõe que você já possua alguma experiência anterior em programação, principalmente JAVA, afinal, muitos dos objetos, classes e diagramas apresentados neste material estão voltados a esta linguagem de programação. É essencial você fazer uso dos conhecimentos adquiridos em disciplinas anteriores para então conseguir acompanhar o desenvolvimento de um sistema e, assim, auxiliar você na construção do entendimento em programação orientada a objetos.

Aproveito a oportunidade para destacar a importância de desenvolver as autoatividades, afinal, cada exercício deste caderno foi desenvolvido para a fixação de conceitos por meio da prática. Em caso de dúvida na realização das atividades, sugiro que você entre em contato com seu tutor externo ou com a tutoria da UNIASSELVI, não prosseguindo as atividades sem ter sanado todas as dúvidas que irão surgindo.

Vale destacar a necessidade de dedicação e de muita determinação, afinal, a Programação Orientada a Objetos exige de você bem mais do que apenas este caderno para sua total compreensão. Aqui você recebe somente um início, ou seja, os conceitos de determinados pontos importantes na programação, porém, é somente na prática que você consegue compreender o mundo da programação como um todo.

Lembre-se de que o mundo da informática é encantador, assim, seu entusiasmo por este universo depende somente de você, destacando neste momento a compreensão da lógica envolvida no processo de construção de programas. Por este motivo, destaco uma frase que considero importante no caso da programação, afinal: “Para se ter sucesso, é amar de verdade o que se faz. Caso contrário, levando em conta apenas o lado racional, você simplesmente desiste. É o que acontece com a maioria das pessoas” (Steven Jobs – criador da Apple).

Bom estudo! Sucesso na sua trajetória acadêmica e profissional!

Simone Cristina Aléssio

IV

Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades em nosso material.

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato mais prático, que cabe na bolsa e facilita a leitura.

O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade de estudá-lo com versatilidade nas telas do celular, tablet ou computador. Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto em questão.

Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa continuar seus estudos com um material de qualidade.

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de Desempenho de Estudantes – ENADE. Bons estudos!

NOTA

VII

UNIDADE 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS .......................................................................................... 1

TÓPICO 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML .................................................................................................... 3

1 INTRODUÇÃO ..................................................................................................................................... 32 ORIENTAÇÃO A OBJETOS ............................................................................................................... 5

2.1 ABSTRAÇÃO .................................................................................................................................... 52.2 CLASSE ............................................................................................................................................. 6

2.2.1. Método .................................................................................................................................... 72.2.2 Responsabilidades .................................................................................................................. 72.2.3 Tipos de relacionamento entre classes ................................................................................. 82.2.4 Mensagem ................................................................................................................................ 102.2.5 Objeto........................................................................................................................................ 10

3 PROJETO ORIENTADO A OBJETOS .............................................................................................. 104 AS VÁRIAS OPÇÕES DA UML ........................................................................................................ 11

4.1 CONCEITOS DA ESTRUTURA DA UML ................................................................................... 124.1.1 Itens ........................................................................................................................................... 124.1.2 Itens estruturais ....................................................................................................................... 124.1.3 Itens comportamentais ........................................................................................................... 154.1.4 Itens de agrupamento ............................................................................................................ 154.1.5 Item anotacional ...................................................................................................................... 16

4.2 DIAGRAMAS ................................................................................................................................... 16RESUMO DO TÓPICO 1........................................................................................................................ 19AUTOATIVIDADE ................................................................................................................................. 20

TÓPICO 2 – MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, DIAGRAMA DE CASOS DE USO ......................................................................................................... 21

1 INTRODUÇÃO ..................................................................................................................................... 212 UML ......................................................................................................................................................... 223 DIAGRAMAS DA UML ...................................................................................................................... 23

3.1 DIAGRAMAS ESTRUTURAIS .................................................................................................. 253.2 DIAGRAMAS COMPORTAMENTAIS .................................................................................... 25

4 DIAGRAMAS COMPORTAMENTAIS .......................................................................................... 264.1 DIAGRAMA DE CASOS DE USO ................................................................................................ 274.2 ELEMENTOS DO DIAGRAMA DE CASOS DE USO ................................................................ 274.3 ELEMENTO ATORES ..................................................................................................................... 284.4 ELEMENTO CASOS DE USO ........................................................................................................ 28

4.4.1 Descrição .................................................................................................................................. 295 FLUXO DE EVENTOS ......................................................................................................................... 29

5.1 FLUXO BÁSICO ............................................................................................................................... 30

sumáriO

VIII

5.2 SUBFLUXO ....................................................................................................................................... 305.2.1 Pontos de extensão ................................................................................................................. 31

5.3 FLUXO ALTERNATIVO ................................................................................................................. 316 ELEMENTO RELAÇÕES ..................................................................................................................... 32

6.1 ASSOCIAÇÃO .................................................................................................................................. 326.2 ATOR X ATOR .................................................................................................................................. 326.3 ATOR X CASO .................................................................................................................................. 326.4 ELEMENTO DEPENDÊNCIA - INCLUSÃO E EXTENSÃO .................................................... 33

7 EXTENSÃO ............................................................................................................................................ 348 ELEMENTO GENERALIZAÇÃO/ESPECIALIZAÇÃO ................................................................ 349 DICAS IMPORTANTES ...................................................................................................................... 36RESUMO DO TÓPICO 2........................................................................................................................ 39AUTOATIVIDADE ................................................................................................................................. 40

TÓPICO 3 – DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS .............................................................................................. 431 INTRODUÇÃO ..................................................................................................................................... 432 AÇÃO ...................................................................................................................................................... 453 ATIVIDADES ........................................................................................................................................ 454 EVENTOS ............................................................................................................................................... 455 NÓS DE CONTROLE .......................................................................................................................... 456 PONTOS DE EXTENSÃO ................................................................................................................... 457 OUTROS RECURSOS EM DIAGRAMAS DE ATIVIDADES .................................................... 478 RELAÇÃO COM OUTROS DIAGRAMAS ..................................................................................... 479 EXEMPLO DE CRIAÇÃO DE DIAGRAMA DE ATIVIDADES ................................................. 48LEITURA COMPLEMENTAR ............................................................................................................... 53RESUMO DO TÓPICO 3........................................................................................................................ 61AUTOATIVIDADE ................................................................................................................................. 62

UNIDADE 2 – DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO) ...................................... 65

TÓPICO 1 – DIAGRAMAS DE INTERAÇÃO .................................................................................. 671 INTRODUÇÃO ..................................................................................................................................... 672 DIAGRAMA DE SEQUÊNCIA .......................................................................................................... 67

2.1 TIPOS DE MENSAGEM ................................................................................................................. 682.2 DIAGRAMA DE COMUNICAÇÃO ............................................................................................. 70

2.2.1 Principais componentes: objetos, mensagens e vínculo .................................................... 712.2.2 Notação: semelhante ao Diagrama de Sequência .............................................................. 722.2.3 Atores ........................................................................................................................................ 732.2.4 Condições ................................................................................................................................. 732.2.5 Autochamadas ........................................................................................................................ 742.2.6 Exemplo de Diagrama de Comunicação ............................................................................. 74

2.3 DIAGRAMA DE TEMPO ............................................................................................................... 752.4 DIAGRAMA DE VISÃO GERAL .................................................................................................. 76

RESUMO DO TÓPICO 1........................................................................................................................ 77AUTOATIVIDADE ................................................................................................................................. 79

TÓPICO 2 – DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES1 INTRODUÇÃO ..................................................................................................................................... 812 DIAGRAMA DE CLASSES ................................................................................................................ 81

2.1 CENÁRIO .......................................................................................................................................... 82

IX

2.2 IDENTIFICAR OS OBJETOS TANGÍVEIS ................................................................................... 842.3 AGRUPAR OS OBJETOS POR SEMELHANÇA ......................................................................... 852.4 DELIMITAR CLASSES REDUNDANTES OU QUE NÃO SÃO NECESSÁRIAS .................. 852.5 MONTANDO O DIAGRAMA DE CLASSE ................................................................................ 852.6 REALIZANDO AS PRIMEIRAS LIGAÇÕES ............................................................................... 86

3 DIAGRAMA DE CLASSE COMPLETO .......................................................................................... 883.1 DIAGRAMA DE PACOTES ........................................................................................................... 89

3.1.1 Definindo as classes de um Pacote ....................................................................................... 903.1.2 Principais componentes: pacotes .......................................................................................... 91

RESUMO DO TÓPICO 2........................................................................................................................ 93AUTOATIVIDADE ................................................................................................................................. 95

TÓPICO 3 – DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPONENTES .............. 971 INTRODUÇÃO ..................................................................................................................................... 972 PRINCIPAIS COMPONENTES: OBJETOS, RELACIONAMENTOS .................................... 973 DIAGRAMA DE COMPONENTES .................................................................................................. 99

3.1 PRINCIPAIS COMPONENTES: COMPONENTES, INTERFACES, CLASSES E RELACIONAMENTOS .................................................................................................................. 993.1.1 Componente ..........................................................................................................................1003.1.2 Objetivos ................................................................................................................................1003.1.3 Diagrama de Componentes .................................................................................................101

LEITURA COMPLEMENTAR .............................................................................................................103RESUMO DO TÓPICO 3......................................................................................................................107AUTOATIVIDADE ...............................................................................................................................108

UNIDADE 3 – DIAGRAMAS ESTRUTURAIS ...............................................................................109

TÓPICO 1 – DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA ......................1111 INTRODUÇÃO ...................................................................................................................................1112 PRINCIPAIS COMPONENTES .......................................................................................................1123 DIAGRAMA DE ESTRUTURA COMPOSTA ..............................................................................113RESUMO DO TÓPICO 1......................................................................................................................117AUTOATIVIDADE ...............................................................................................................................118

TÓPICO 2 – INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO DESENVOLVIMENTO USANDO UML ..........................................................................................1191 INTRODUÇÃO ...................................................................................................................................1192 EXEMPLO DE DESENVOLVIMENTO DE PROJETOS USANDO UML ...............................119RESUMO DO TÓPICO 2......................................................................................................................123AUTOATIVIDADE ...............................................................................................................................124

TÓPICO 3 – ESTUDO DE CASO .......................................................................................................1251 INTRODUÇÃO ...................................................................................................................................1252 NECESSIDADE DE COMPREENDER OS PROCESSOS DA ORGANIZAÇÃO .................126

2.1 O MAPEAMENTO DE PROCESSOS .........................................................................................1272.1.1 Fluxograma ...........................................................................................................................1282.1.2 SADT (Structured Analysis and Design Technic) .................................................................1292.1.3 IDEF3 .....................................................................................................................................1292.1.4 UML (Unified Modeling Language) .......................................................................................1302.1.5 Diagrama de Atividades ......................................................................................................1302.1.6 Aplicação do Diagrama de Atividades da UML ..............................................................131

X

2.1.7 Avaliação da Aplicação do Diagrama de Atividades.......................................................1362.1.8 Conclusões ............................................................................................................................137

LEITURA COMPLEMENTAR .............................................................................................................138RESUMO DO TÓPICO 3......................................................................................................................150AUTOATIVIDADE ...............................................................................................................................151

REFERÊNCIAS .......................................................................................................................................153

1

UNIDADE 1

REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO

DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS

DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS

OBJETIVOS DE APRENDIZAGEM

PLANO DE ESTUDOS

A partir desta unidade, você será capaz de:

• revisar conceitos de Orientação a Objetos;

• revisar conceitos de UML;

• conhecer a visão comportamental dos diagramas da UML;

• elaborar diagramas de casos de uso, de atividades e máquina de estados.

Esta unidade de ensino contém três tópicos. Ao final de cada um deles você encontrará atividades que contribuirão para a apropriação dos conteúdos.

TÓPICO 1 – REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML

TÓPICO 2 – MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML, DIAGRAMA DE CASOS DE USO

TÓPICO 3 – DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS

3

TÓPICO 1UNIDADE 1

REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS,

REVISÃO DE CONCEITOS DA UML

1 INTRODUÇÃO

Este tópico reapresenta conceitos que são o alicerce da disciplina, bem como os seus principais autores, conforme mostra a Figura 1.

FIGURA 1 – ORIGEM E EVOLUÇÃO DA UML

Origem e evolução da UML1962-1963

1962 - Krysten Nygaard e Ole-JohanDahl, pesquisadores do Centro de Computação da Noruega, em Oslo,criam a linguagem Simula, derivadado Algol, introduzindo os primeirosconceitos de orientação a objetos.

1963 - Ivan Sutherland desenvolve,no MIT (Massachusets Institute ofTecnology), nos Estados Unidos, oSketchpad, primeiro editor gráficopara desenhos orientado a objetos.O Sketchpad usava conceitos deinstância e herança.

IvanSuthorland

KrystenNygaard

1969 1970 - 1983

AlanCurtis Kay

Alan Curtis Kay apresenta sua tesede doutorado intitulada The

Reactive Engine na Universidadede Utah, na qual propõe

uma linguagem (Flex),que contém conceitos

de orientaçãoa objetos.

É lançada linguagem de programaçãoSmaltalk, desenvolvida no centro depesquisas da Xerox em Palo Alto, Estados Unidos. Essa foi por muito tempo a única linguagem 100% orientada a objetos.

1980 - Surge a linguagem de programaçãoC++, que também pode serorientada a objetos.

1983 - Jean Ichbiah cria a linguagemADA a pedido do Departamentode Defesa dos Estados Unidos,também orientada a objetos.

UNIDADE 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL: CASOS DE USO, DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS

4

1985 - 1989

BertrandMeyer

Bertrand Meyer lança a linguagemEifel, orientada a objetos.

1988 - Sally Shlaer e Stepen Mellorpublicam o livro Object-OrientedSystems Analysis: Modeling the World inData, que propõe uma técnica paraanálise e projetos orientados a objeto.

1989 - É criado o OMG (Object Management Group), que aprovapadrões para aplicações orientadasa objeto.

Peter Coad e Ed Yourdon lançam o livroObject - Oriented Analysis, tambémcontendo técnicas para análise eprojetos orientados a objeto.

Rebecca Wirfs - Brock, Brian Wilkersone Lauren Wiener publicam o livroDesigning Object - Oriented Software,tratando de técnicas de modelagemorientada a objetos.

1992 - Ivar Jacobson, Magnus Christerson,Patrik Jonsson e Gunnar Overgaardlançam o livro Object - OrientedSoftware Enginnering: A Use Case Driven

1990 - 1993

1970 - 1983Approach, também sobre técnicasde orientação a objetos.D. Embley, B. Kurtz, e S. Woodfieldpublicam o livro Object - OrientedSystem Analysis. AMadel-Driven Approach.

1993 - Grady Boochlança seu Booch Methodcom técnicas paraanálise e projetoorientado a objetos.

É lançada linguagem de programaçãoSmaltalk, desenvolvida no centro depesquisas da Xerox em Palo Alto, Estados Unidos. Essa foi por muito tempo a única linguagem 100% orientada a objetos.

1980 - Surge a linguagem de programação C++, que também pode ser orientada a objetos.

1983 - Jean Ichbiah cria a linguagemADA a pedido do Departamentode Defesa dos Estados Unidos,também orientada a objetos.

JamesMartin

JamesGosling

FONTE: Piva (2010)

Este tópico foi criado com o objetivo de revisar conceitos da disciplina de Análise Orientada a Objetos I, reapresentando os conceitos da UML, que possibilita visualização, especificação, construção e documentação de requisitos no desenvolvimento de software com orientação a objetos. Será exibido um pequeno histórico da UML e principais conceitos da metodologia orientada a objetos e sua representação na UML.

Três grandes nomes criaram a UML. Dois deles são norte-americanos: Grady Booch e James Rumbaugh, o terceiro é o suíço Ivar Jacobson. Juntos, em 1995 lançaram a UML 0. Unificando os seus três métodos de estudos desenvolvidos individualmente:

Método de Booch: desenvolvido por Grady Booch, da Rational Software Corporation, expressivo principalmente nas fases de projeto e construção de sistemas.

OOSE (Object-Oriented Software Engineering), de Ivar Jacobson, que fornecia excelente suporte para casos de usos como forma de controlar a captura de requisitos, a análise e o projeto de alto nível.

TÓPICO 1 | REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS, REVISÃO DE CONCEITOS DA UML

5

OMT (Object Modeling Technique), de James Rumbaugh, que é um método de modelagem e projeto orientado a objetos publicado em 1991 por James Rumbaugh, Michael Blaha, Willian Premerlani, Frederick Eddy e Willian Lorensen, no livro Object-Oriented Modeling and Design.

FONTE: Disponível em: <http://issuu.com/geeadcps/docs/livro3_alta/81>. Acesso em: 5 out. 2015.

Kay foi considerado o pai da orientação a objetos. Foi ele quem definiu o computador como um organismo vivo, promovendo a independência das células, que, mesmo independentes, deveriam se relacionar ou juntar-se a outras, a fim de atingir um objetivo específico.

À época do surgimento da linguagem Smalltalk, Kay era pesquisador da Xerox, e, em 1970, foi o primeiro a usar o termo “Orientação a Objetos”.

A UML oferece suporte em todas as etapas do desenvolvimento de software. Por este motivo, atualmente é considerada um padrão de desenvolvimento quando se utiliza da orientação a objetos.

2 ORIENTAÇÃO A OBJETOS

O objetivo da orientação a objetos é o de aproximar o desenvolvimento de software da realidade dos acontecimentos, do fluxo real da informação. Para isso, cria elementos e dados que tenham funcionalidades em si mesmos.

O conceito continua evoluindo, pois ainda existem limitações de hardware que se relacionam a problemas de acesso e armazenamento de dados, e de software relativas a processos do sistema operacional e a falta de sistemas gerenciadores de banco de dados orientados a objetos (PIVA, 2010).

2.1 ABSTRAÇÃO

Abstração é uma característica específica da entidade, fazendo com que a mesma se torne distinta de todas as outras entidades envolvidas em um modelo de dados.

A abstração foca o escopo da entidade. Por exemplo, ao pensarmos na entidade PRODUTO, não precisamos pensar em todos os atributos desta entidade. Posso focar a atenção apenas nos atributos principais e essenciais, os quais serão a característica desta entidade e que a tornarão exclusiva dentro de um modelo, na análise e desenvolvimento do sistema.


6

2.2 CLASSE

Para os autores Booch, Rumbaugh e Jacobson (2005), a classe descreve vários objetos, que juntos compartilham os mesmos atributos, operações, relacionamentos e semântica. A representação completa de uma classe tem quatro divisões, conforme podemos visualizar na Figura 2.

FIGURA 2 – REPRESENTAÇÃO DE UMA CLASSE

Carro

- nomeFabricante: String- nomeModelo: String- cor: String- numeroPortas: Int- anoFabricação: Int- velocidadeMaxima: double

+ abrirPortas( ): vold+ fecharPortas( ): vold+ ligar( ): vold+ desligar( ): vold+ acelerar( ): vold+ frear( ): vold+ trocarMarcha( ): vold

Responsabilidades

- Se locomover na velocidade e direção indicados pelo usuário.- Acelerar quando solicitado.- Frear quando solicitado.

Nome da classe

Responsabilidades

Métodos

Atributos

Defi nição da classesegundo UML 2.

FONTE: Piva (2010)

FIGURA 3 – OUTRA FORMA DE REPRESENTAÇÃO DE CLASSE

Carro

- nomeFabricante: String- nomeModelo: String- cor: String- numeroPortas: Int- anoFabricação: Int- velocidadeMaxima: double

+ abrirPortas( ): vold+ fecharPortas( ): vold+ ligar( ): vold+ desligar( ): vold+ acelerar( ): vold+ frear( ): vold+ trocarMarcha( ): vold

Carro

Outra forma derepresentar umaclasse em UML 2.0.

FONTE: Piva (2010)

Nome da classe: Cada classe deve ter um nome único, que seja capaz de diferenciar a mesma de outras classes (BOOCH; RUMBAUGH; JACOBSON, 2005).


7

Atributo: Pode ser entendido como um campo, uma propriedade que mantém valores cujas instâncias desse atributo podem apresentar (BOOCH; RUMBAUGH; JACOBSON, 2005).

2.2.1. Método

Para modificar o seu comportamento, um objeto da classe pode solicitar um serviço. É algo que muda o objeto e que pode afetar todos os objetos da classe (BOOCH; RUMBAUGH; JACOBSON, 2005). Relembre alguns dos principais métodos, conforme descrição abaixo:

Os métodos especiais

• Construtor: é o método que constrói, isto é, reserva o espaço em memória onde serão armazenadas as informações daquele objeto da classe.

• Get: é o método que apresenta o valor armazenado em determinado atributo de um objeto.

• Set: dá um valor a um atributo.

Os métodos Get e Set encapsulam os atributos de uma classe, garantindo que as alterações nos atributos sejam feitas única e exclusivamente por eles. Os atributos permanecem com visibilidade privada. Lembrando:

Get (para retornar o valor que está no atributo). Set (para atribuir um valor a ele).

Normalmente, no processo de desenvolvimento são adotados um método Set e um método Get para cada atributo da classe.

• Destrutor: destrói o objeto criado da memória, liberando o espaço de memória alocado na sua criação.

• Assinatura: é a primeira linha da definição de um método, no qual podemos observar sua visibilidade, seu nome, seus parâmetros de entrada e de retorno.

2.2.2 Responsabilidades

As responsabilidades remetem às obrigações das classes, que, quando criadas, estabelecem que todos os seus objetos terão o mesmo estado e tipo de comportamento. Por isso é possível representar uma classe apenas com seu nome ou com nome dos principais atributos e principais métodos, de acordo com o que se quer analisar ao iniciar a criação dos diagramas.


8

2.2.3 Tipos de relacionamento entre classes

Dependência, associação e herança estabelecem os principais relacionamentos entre as classes.

1) Dependência: determina que um objeto de uma classe possa usar as informações e serviços de outra classe, que um objeto de uma classe use informações e serviços de um objeto de outra classe. A dependência é representada grafi camente por uma linha tracejada com uma seta indicando o sentido da dependência. Verifi que a representação na fi gura a seguir. A classe Janela é dependente da classe Evento.

FIGURA 4 – DEPENDÊNCIA DA UML

Janela

- largura: double- altura: double

+ abrir ( ): void+ fechar ( ): void+ tratarEvento ( ): void

Evento

- nome: String

+ start ( ): void

Representação deuma dependênciaem UML 2.0.

Exemplo deassociação entreclasses UML.

Funcionário

- salario: double- nroCarteiraProfi ssional: String

Empresa

- nome: String- ramoAtividade: String- cnpj: String

Trabalha para ►

1..* *

empregadortrabalhador

FONTE: Piva (2010)

2) Associação: é um relacionamento de estrutura, que aponta os objetos de uma classe que estão conectados a objetos de outra classe estrutural que especifi ca objetos de uma classe conectados a objetos de outra classe. A associação é representada por uma linha interligando as duas classes.

FIGURA 5 – ASSOCIAÇÃO ENTRE CLASSES

FONTE: Piva (2010)

A fi gura a seguir apresenta um exemplo de agregação, que é um tipo de associação entre classes na qual é mostrada a relação todo-parte entre as classes. Uma classe é a parte, e a outra, o todo.


9

FIGURA 6 – ASSOCIAÇÃO ENTRE CLASSES

Empresa

- nome: String- ramoAtividade: String- cnpj: String

Representação daagregação entreclasses UML 2.0.

Representação deuma composiçãoUML 2.0.

1

*

1

*

Departamento

- nome: String

ItemdePedido

-- descrição: String- quantidade: Int- precoUnitario: double

Pedido

- numero: Int- data: Date- valor Total: double

FONTE: Piva (2010)

Observe, na fi gura anterior, que uma empresa é formada por vários departamentos. Pode-se ver ainda que cada departamento está associado a uma empresa.

Não podemos esquecer-nos da composição, que nada mais é do que uma forma de agregação, tempo de vida semelhante entre as partes pelo todo. Pode-se afi rmar que numa relação de composição só faz sentido existir a parte se houver o todo (PIVA, 2010).

3) Herança: na herança, classes mais específi cas assumem a estrutura e o comportamento de classes mais gerais. A representação da Herança pode ser entendida pela representação da Figura 7, onde a classe Pessoa possui os atributos nome e cpf e pode executar os métodos de andar e falar. Já a classe Funcionario herda os atributos e métodos da classe Pessoa, possui nome, cpf, salário e nroCarteiraProfi ssional, podendo executar os métodos andar, falar e trabalhar.

Logo, conclui-se que é a classe pai de Funcionario e que Funcionario é classe fi lha de Pessoa.


10

FIGURA 7 – REPRESENTAÇÃO DE HERANÇA

Pessoa

# nome: String# cpf: String

+ andar ( ): void+ falar ( ): void

Representaçãode herançautilizando UML.

Generalização

Especialização

Funcionario

- salario: double- nroCarteiraProfi ssional: String

+ trabalhar ( ): void

FONTE: Piva (2010)

2.2.4 Mensagem

As mensagens confi guram uma forma de comunicação entre os objetos. Elas carregam informações de uma determinada atividade que está por ser executada. Os seja, objetos trocam informações para tornar possível o funcionamento dos sistemas.

2.2.5 Objeto

É pelo objeto que se concretiza a abstração, através de entidades bem defi nidas, entidades que encapsulam estados e comportamentos; é a instância de uma classe. Utilizando como exemplo um automóvel, podemos pensar nos atributos como sendo: o modelo, cor, ano de fabricação, combustível, e seus métodos como: andar, acelerar, frear, entre outros. Ao pensar nas responsabilidades do automóvel, podemos dizer que ele deve obedecer aos comandos que lhe são impostos, como aceleração, velocidade, trajeto etc. (PIVA, 2010).

3 PROJETO ORIENTADO A OBJETOS

Num projeto é necessário defi nir com precisão quais são as principais classes que irão compor a solução para a construção de determinado software. Em seguida, deve-se estabelecer como os objetos criados a partir dessas classes vão interagir entre si para atingir a solução proposta em termos de desenvolvimento de aplicação.


11

Deve-se projetar todo o funcionamento do sistema em detalhes. Um recurso satisfatório é proposto pela UML, através do uso dos seus diagramas, que permitem definir como funcionará cada um dos itens da solução, até, por exemplo, em que estrutura de hardware e software será implementada e como estarão dispostos componentes da rede envolvida na solução.

É comum, no decorrer do planejamento e desenvolvimento do projeto, o surgimento de novas classes. Estas, geralmente, são responsáveis pela interação do usuário com o sistema em si (PIVA, 2010). Além disso, são definidos e protocolados todos os requisitos necessários para a segurança das informações que serão mantidas pelo sistema. Tudo isso é possível de ser realizado mantendo-se o uso e aplicação da UML, cujas ferramentas permitem o detalhamento de cada um dos componentes da solução de software.

Na fase da análise do sistema (orientada a objetos) devemos concentrar nossos esforços a fim de mapear o funcionamento e comportamento das classes para que o sistema funcione da forma como foi projetado em termos de estrutura de rede, software e hardware (PIVA, 2010).

4 AS VÁRIAS OPÇÕES DA UML

Segundo Piva (2010), devemos estar atentos ao que é estático e dinâmico ao utilizarmos a UML.

Como estático podemos entender:

• definição das classes;• modularização;• as camadas e a configuração do hardware.

Como processo dinâmico podemos classificar as mudanças de estado que os itens podem sofrer no decorrer da execução do software, por exemplo, pelas alterações ocasionadas pelas trocas de mensagens entre os itens nesse momento.

Ainda de acordo com o Piva (2010) podemos perceber cinco diferentes visões proporcionadas pela UML durante a construção de modelos de software. São elas:

• Visão de casos de uso: permite melhor compreensão do problema a ser resolvido, ajudando na definição das fronteiras do sistema, seus principais usuários e as principais funcionalidades a serem implementadas.

• Visão de projeto: auxilia na análise da estrutura e das funcionalidades esperadas da solução.

• Visão de processo: também chamada de visão de interação, foca o fluxo de controle entre os diversos componentes da solução, permitindo também a análise de seu desempenho, a sincronização e a concorrência entre seus componentes, necessária para o perfeito funcionamento da solução.


12

• Visão de implementação: ajuda a definir a estrutura da solução, isto é, os arquivos de instalação, seu controle de versões.

• Visão de implantação: trata da estrutura de hardware e software, ou seja, do ambiente em que a solução será implementada.

4.1 CONCEITOS DA ESTRUTURA DA UML

A formação da UML tem seu alicerce em três componentes básicos:

• blocos de construção;• regras que restringem como os blocos de construção podem ser associados

entre si;• mecanismos de uso geral, que dão mais clareza às definições criadas pelos

blocos de construção. Estes, por sua vez, são de três tipos: itens, relacionamentos e diagramas (PIVA, 2010).

4.1.1 Itens

São as abstrações em si e a base da UML. Os itens mantêm relacionamentos, que são mantidos pelos diagramas. Existem diferentes tipos de itens, que podem ser classificados em quatro grupos: estruturais, comportamentais, de agrupamento e anotacionais, que serão estudados no decorrer deste caderno.

4.1.2 Itens estruturais

São responsáveis por definir a estrutura da solução.

São formados por:

• classes;• as interfaces;• as colaborações;• os casos de uso;• os componentes;• os artefatos;• os nós.

Para prosseguirmos, torna-se necessário o entendimento acerca dos elementos mencionados acima, conforme esclarecimento proposto por Piva (2010, p. 173):

Classes: são os elementos básicos da orientação a objetos e, consequentemente, da UML.


13

Interfaces: são as funcionalidades a serem implementadas por uma classe ou por um componente. Demonstram o comportamento visível de uma classe, mas nunca a implementação de tal comportamento, pois contêm apenas a assinatura dos métodos, e sua implementação é feita pelas classes que herdam seu comportamento. Servem para defi nir comportamentos padronizados para conjuntos de classes e itens. As interfaces são representadas por um círculo.

Colaboração: são agrupamentos de classes, relacionamentos e interfaces que constituem uma unidade do sistema. Dizemos que essa unidade é maior que a soma das classes e relacionamentos implementados. São representados por uma elipse tracejada com o nome da colaboração ao centro. A colaboração serve também para nos dar uma visão em nível mais alto de abstração, quando não é necessário entrar em todos os detalhes de determinado item em análise.

FIGURA 8 – COLABORAÇÃO

Controlede Estoque

SolicitarPreço

FONTE: Piva (2010)

Casos de uso: descrevem uma sequência de ações a serem executadas pelos componentes da solução. São ativados por um ator, servem de base para defi nirmos comportamentos dos elementos da solução de software e são realizados por uma colaboração. São representados por uma elipse com o nome da operação que implementa no centro (PIVA, 2010, p. 174).

FIGURA 9 – REPRESENTAÇÃO DE CASOS DE USO

FONTE: Piva (2010)

Componentes: são estruturas que instituem uma funcionalidade de uma solução de software por meio da implementação de uma ou mais interfaces defi nidas. Podem ser substituídos dentro de uma solução por outro componente que implemente todas as suas interfaces, sem prejuízo ao sistema como um todo (PIVA, 2010, p. 174).


14

FIGURA 10 – REPRESENTAÇÃO DE COMPONENTES

FormCliente

<<artefato>>Cliente.class

imprimirNota Fiscal

FONTE: Piva (2010)

Artefato: é um elemento físico do sistema, que pode ser um programa (fonte ou executável), um script do sistema operacional e tudo o mais que pode ser transformado em bits e bytes. É representado por um retângulo com o estereótipo <<artefato>> e o seu nome (PIVA, 2010, p. 174).

FIGURA 11 – REPRESENTAÇÃO DE ARTEFATO

FONTE: Piva (2010)

Nó: representa um recurso de computação. Pode ser um servidor, um computador cliente, um switch, um hub etc. Qualquer elemento computacional que faça parte da arquitetura na qual será implementada a solução pode ser defi nido como um nó. Em UML é desenhado como um cubo com seu nome dentro (PIVA, 2010, p. 174).

FIGURA 12 – REPRESENTAÇÃO DE NÓ

Servidor

FONTE: Piva (2010)

Atividade: “é um comportamento que especifi ca a sequência de etapas realizadas por um processo computacional. É representada em UML por um retângulo de vértices arredondados” (PIVA, 2010, p. 174).


FONTE: Piva (2010)


15

EmEspera

4.1.3 Itens comportamentais

São os itens que defi nem as partes dinâmicas dos modelos UML. São também chamados de verbos do modelo. Constituem itens: interações, máquina de estados e atividades.

Interações: são os conjuntos de troca de mensagens entre objetos, também chamados de comportamento. Em UML as mensagens são representadas por uma seta traçada sob seu nome.

Máquina de estados: “especifi ca os diversos estados pelos quais pode passar um objeto ou uma interação em seu ciclo de vida. Sua defi nição inclui outros componentes, como estados, transições, eventos e atividades. Em UML é representada por um retângulo com os vértices arredondados” (PIVA, 2010, p. 174).

FIGURA 14 – REPRESENTAÇÃO DE MÁQUINA DE ESTADOS

FONTE: Piva (2010)

4.1.4 Itens de agrupamento

Servem para agrupar os demais itens da UML em bloco, permitindo uma melhor organização do projeto. É composto apenas pelo item pacote (PIVA, 2010).

Pacote: “permite a inclusão de itens em seu interior para organizar o projeto, tornando-o modular e mais organizado. É conceitual, não existindo em tempo de execução. É representado por uma pasta, que pode receber apenas seu nome ou a visualização dos itens que a compõem” (PIVA, 2010, p. 175).

FIGURA 15 – REPRESENTAÇÃO DE PACOTE

Controle

FONTE: Piva (2010)


16

4.1.5 Item anotacional

É o componente que permite a inserção de comentários nos modelos, tornando-os mais claros e inteligíveis. É composto apenas pelo item nota.

Nota: tem como objetivo inserir comentários em um modelo para deixá-lo mais compreensível. É representado por um retângulo com a ponta superior direita dobrada para dentro. Em seu interior são inseridos os comentários pertinentes ao que se quer explicar melhor dentro do modelo. Também pode ser utilizada uma linha tracejada para apontar exatamente a que ponto do modelo se destina a explicação da nota (PIVA, 2010, p. 175).

FIGURA 16 – REPRESENTAÇÃO DE NOTA

Esta classe faz a conexãoentre o software aplicativoe o sistema operacional.

FONTE: Piva (2010)

4.2 DIAGRAMAS

A versão 2.0 da UML traz consigo 13 diagramas, divididos em quatro grupos:

• diagramas estruturais;• diagramas comportamentais;• diagramas de interação;• diagramas de implementação.

A fi gura a seguir permite uma melhor visualização dos diagramas e os grupos aos quais cada um pertence.


17

FIGURA 17 – DIAGRAMAS DA UML

Diagramasda UML

DiagramasEstruturais

DiagramasComportamentais

Diagramade Objetos

Diagrama deEstrutura Composta

Diagrama deimplementação

Diagrama deComponentes

Diagrama deImplantação Diagrama

de SequênciaDiagrama de

TemporaçãoDiagrama de

Colaboração

Diagrama de VisãoGeral da Interação

Diagramade Interação

Diagrama deAtividades

Diagramade Classes

Diagramade Pacotes

Diagrama deCasos de Uso

Diagramade Transiçõesde Estados

Diagramade Objetos

Diagrama de

Diagramade Classes

Diagramade Pacotes

Comportamentais

Diagrama de

implementaçãoimplementação

FONTE: Piva (2010)

Adiante estudaremos em detalhes cada um dos diagramas apresentados. Para facilitar nosso entendimento acerca da elaboração de cada diagrama, precisamos estar atentos às cinco regras propostas pela UML para uma adequada construção dos mesmos.

São elas:

• Nome: sempre devemos lembrar que o nome de um item deve deixar clara sua formação, suas ações e responsabilidades. Não devemos nos esquecer também de que esse nome é único dentro de um modelo.

• Escopo: todo item inserido em um modelo deve mostrar claramente quais são seus limites, o que implementa e quando pode ser utilizado.

• Visibilidade: indica que é necessário também que fi que claro quando um item estará disponível para ser utilizado e que ações estarão disponíveis por seu intermédio.

• Integridade: também é importante levar em conta na criação de um item a defi nição clara de como este se relaciona e a consistência de tal relacionamento.

• Execução: deve estar evidente ainda o que o modelo representa e/ou simula. O que queremos observar com a criação desse modelo.



18

As regras definem que ao inserir um item em um diagrama, você tem de se preocupar com as características apresentadas acima, para que consiga criar modelos bem elaborados e consistentes.

19

Neste tópico você aprendeu que:

• A UML oferece diversos subsídios para a criação de modelos claros que nos auxiliam na construção de soluções de software de qualidade.

• A UML permite também a criação de modelos que simulam o comportamento do software em construção em diversos aspectos. Mas nunca se esqueça: sempre caberá ao desenvolvedor a responsabilidade de usar as informações de modo a obter soluções de qualidade de acordo com as expectativas do usuário e que sejam capazes de produzir os melhores resultados possíveis.

• Ao utilizar a UML precisamos de bom senso para oferecer soluções adequadas e no prazo esperado pelo usuário, criando modelos apenas para as partes que realmente demandam definição mais aprofundada.

RESUMO DO TÓPICO 1

20

1 Cite os objetivos da UML.

2 Defina classe.

3 Defina objeto.

4 O que você entende por pacote?

5 O que é um diagrama?

AUTOATIVIDADE

21

TÓPICO 2

MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML,

DIAGRAMA DE CASOS DE USO

UNIDADE 1

1 INTRODUÇÃO

Desenvolver um software exige do gestor do projeto a habilidade de equilibrar pessoas, atividades, tecnologias e metodologias. Projetos de softwares são cercados por riscos desde a sua fase embrionária. Com isso, os modelos surgem como uma alternativa ágil para tornar a correção mais rápida e com custo reduzido. O próprio uso de modelos já possibilita reduzir o custo do desenvolvimento das atividades, pois permite prever o comportamento do sistema quando o mesmo estiver finalizado e em uso.

Uma forma mais eficiente de pensar em modelagem e desenvolvimento de projetos é a proposta orientada a objetos, que organiza os problemas em torno de situações reais, ou seja, como elas de fato acontecem na prática, e isso impõe uma forma completamente diferente de pensar e organizar a solução, se comparado à forma como o pensamento estruturado apresenta a solução (BOOCH, 1994).

A grande vantagem da orientação a objetos é que os projetos são mais facilmente compreendidos, e em consequência, mais facilmente construídos, pelos profissionais envolvidos no projeto. A “partícula” fundamental desta metodologia é o objeto, que traz consigo o seu comportamento, que pode vir acrescido de regras, conhecimentos, responsabilidades e um ciclo de vida definido. Depois de modelado não sofre modificações, sendo agregado ao que já existe no sistema. A figura a seguir mostra as visões de um projeto orientado a objetos.


22

FIGURA 18 – VISÕES DE UM PROJETO COM UML

Visão deProjeto

FuncionalidadeVocabulário

Visão doProcesso

DesempenhoEscalabilidadeThroughput

Visão daImplantação

Topologia do SistemaDistribuiçãoInstalação

Visão daImplementação

Codifi caçãoMontagem

Visão deCaso de Uso

Conceitual Físico

Workfl ow de Design (Arquitetura):Introdução. UML, Visões:

Des

enha

ndo

Com

pone

nte

de S

oftw

are

com

UM

L

FONTE: Piva (2010)

2 UMLUML signifi ca Linguagem de Modelagem Unifi cada de projetos orientados

a objetos. É uma linguagem, não podendo ser considerada um método.

A UML é uma linguagem padrão de notação de projetos.

Por notação entende-se especifi car, visualizar e documentar os elementos de um sistema OO. A UML é importante: serve como linguagem para expressar decisões de projeto que não são óbvias ou que não podem ser deduzidas do código; provê uma semântica que permite capturar as decisões estratégicas e táticas;provê uma forma concreta o sufi ciente para a compreensão das pessoas e para ser manipulada pelas máquinas.

NOTA

A UML não depende das ferramentas de programação utilizadas no desenvolvimento do projeto.

Além de dar suporte a todos os processos de engenharia de software necessários ao projeto, a UML pode ser defi nida como a linguagem de modelagem padrão no desenvolvimento de sistemas distribuídos, por exemplo, pois, basicamente, sua característica principal baseia-se em um conglomerado de técnicas de notação gráfi ca para criar a modelagem visual dos sistemas. É

TÓPICO 2 | MODELO DE DESENVOLVIMENTO, DIAGRAMAS DA UML,

23


É uma linguagem de modelagem única e atualmente muito utilizada!

NOTA

A UML não tem a preocupação de demonstrar como o trabalho ou as atividades envolvidas no projeto serão executados. O objetivo da linguagem é descrever "o que fazer", “como fazer", "quando fazer" e "por que fazer".

A Linguagem Unificada de Modelagem utiliza diagramas que podem ser usados de forma combinada a fim de obter todas as visões e aspectos do sistema.

3 DIAGRAMAS DA UMLDiagramas, na verdade, são gráficos que permitem visualizar o sistema de

formas diferentes. Pela notação dos diagramas da UML é possível descrever de forma ágil e objetiva todos os aspectos da modelagem de dados, sendo que cada diagrama tem seu significado, sua notação e a forma de ser utilizado (ANDRADE, 2007). Os diagramas da UML estão classificados em dois grupos distintos: estruturais e comportamentais, sendo que o primeiro grupo mostra tudo o que não muda no sistema, e o segundo mostra as reações e evoluções do mesmo.

Cada diagrama analisa o sistema, ou parte dele, sob uma determinada ótica (GUEDES, 2007).

NOTA

uma ferramenta ágil, pois combina e suporta as melhores técnicas, que vão desde a modelagem dos dados até o levantamento e engrenagem de todos os componentes do sistema.

A figura a seguir mostra todos os diagramas da UML agrupados de acordo com sua classificação. Os diagramas estruturais tratam o aspecto estrutural do ponto de vista do sistema e das classes. São para visualizar, especificar, construir e documentar os aspectos que não são mutáveis (ANDRADE, 2007). Ainda de acordo com o autor, os aspectos estáticos de um sistema de software envolvem a existência e a colocação de itens como classes, interfaces, colaborações, componentes.


24

FIGURA 19 – MODELOS DE DIAGRAMAS DA UML

FONTE: Piva (2010)

Dia

gram

asda

UM

L

Dia

gram

asEs

trutu

rais

Dia

gram

ade

Obj

etos

Dia

gram

a de

Com

pone

ntes

Dia

gram

a de

Impl

anta

ção

Dia

gram

a de

Sequ

ênci

aD

iagr

ama

deTe

mpo

rizaç

ãoD

iagr

ama

deC

olab

oraç

ãoD

iagr

ama

de V

isão

Ger

al d

a In

tera

ção

Dia

gram

a de

Estru

tura

Com

post

a

Dia

gram

a de

Impl

emen

taçã

oD

iagr

ama

de C

lass

esD

iagr

ama

de P

acot

es

Dia

gram

asC

ompo

rtam

enta

is

Dia

gram

ade

Ativ

idad

esD

iagr

amas

de

Inte

raçã

o

Dia

gram

a de

Tran

siçõ

esde

Est

ados

Dia

gram

a de

Cas

os d

e U

so


25

Os diagramas da UML estão divididos em Estruturais e Comportamentais.

3.1 DIAGRAMAS ESTRUTURAIS

• De Classe: Este diagrama é fundamental e o mais utilizado na UML e serve de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes com seus atributos e métodos e os relacionamentos entre classes.

• De Objeto: O Diagrama de Objeto está relacionado com o diagrama de classes e é praticamente um complemento dele. Fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classe em um determinado momento da execução do processo do software.

• De Componentes: Está associado à linguagem de programação e tem por finalidade indicar os componentes do software e seus relacionamentos.

• De Implantação: Determina as necessidades de hardware e características físicas do sistema.

• De Pacotes: Representa os subsistemas englobados de forma a determinar partes que o compõem.

• De Estrutura: Descreve a estrutura interna de um classificador.


3.2 DIAGRAMAS COMPORTAMENTAIS

De Caso de Uso (Use Case): Geral e informal para fases de levantamento e análise de Requisitos do Sistema.

De Máquina de Estados: Procura acompanhar as mudanças sofridas por um objeto dentro de um processo.

De Atividades: Descreve os passos a serem percorridos para a conclusão de uma atividade.

De Interação: Dividem-se em:

o De Sequência: Descreve a ordem temporal em que as mensagens são trocadas entre os objetos.

o Geral interação: Variação dos diagramas de atividades que fornece visão geral dentro do sistema ou processo do negócio.

o De comunicação: Associado ao diagrama de Sequência, complementando-o e concentrando-se em como os objetos estão vinculados.

o De tempo: Descreve a mudança de estado ou condição de uma instância de uma classe ou seu papel durante o tempo.


26

FIGURA 20 – DIAGRAMAS COMPORTAMENTAIS

DiagramasComportamentais

Diagrama deAtividades

Diagrama deTransiçõesde Estados

Diagrama deInteração

Diagrama deCasos de Uso

Diagrama deSequência

Diagrama deTemporização

Diagrama de VisãoGeral da Interação

Diagrama deColaboração

FONTE: Piva (2010)

Os diagramas comportamentais podem ser divididos em:

• Diagramas de Casos de Uso• Diagrama de Atividades• Diagrama de Máquina de Estados• Diagramas de Interação:

o Diagrama de Sequênciao Diagrama de Comunicaçãoo Diagrama de Tempoo Diagrama de Interação Geral

4 DIAGRAMAS COMPORTAMENTAIS

Os diagramas de comportamento têm o mesmo objetivo da modelagem dinâmica do sistema. São usados para visualizar, especificar, construir e documentar os aspectos do sistema que sofrem mudanças ao longo do tempo, como, por exemplo, o fluxo de mensagens e a movimentação física de componentes em uma rede.


Cada diagrama citado acima será estudado posteriormente!

ESTUDOS FUTUROS


27

4.1 DIAGRAMA DE CASOS DE USO

O objetivo principal deste diagrama é propor uma visão de como os usuários interagem com o sistema.

NOTA

Estes diagramas especificam o que o sistema faz, mas não detalham como o trabalho deve ser feito.

FIGURA 21 – EXEMPLO DE DIAGRAMA DE CASO DE USO

Vender CDs

Administrar estoque

Atendente

GerenteFONTE: Tacla (2010)

Diagrama de casos de uso é uma ferramenta de comunicação entre clientes, usuários e desenvolvedores para discutirem e definirem as funcionalidades que devem ser realizadas pelo sistema.

4.2 ELEMENTOS DO DIAGRAMA DE CASOS DE USO

• Atores • Casos de uso • Relacionamentos • Associação • Generalização• Dependência: Extensão e Inclusão


28

De acordo com Tacla (2010), para encontrar os atores de um sistema deve-se sempre examinar a situação, procurando por pessoas ou sistemas no entorno da situação. Para esse processo ser mais eficiente deve-se questionar:

• Quais pessoas ou outras entidades interessam a um requisito funcional?• Quem irá alimentar as informações do sistema e também quem será o receptor

destas informações?• Quais recursos externos são utilizados pelo sistema?• Existem pessoas que desempenham papéis diferentes no sistema?• O sistema interage com outros sistemas que já existem e são usados pela

organização?

4.4 ELEMENTO CASOS DE USO

“A coleção de casos de uso representa todos os modos de execução do sistema do ponto de vista do usuário. Um caso de uso é uma sequência de ações que produz um resultado significativo (com valor) para um ator” (TACLA, 2010, p. 17).

• Quais são as tarefas de cada ator?• Que informações o ator obtém do sistema?• Quem as fornece?• Quem as captura?• Algum ator precisa ser informado sobre eventos produzidos pelo sistema?

o Sim => casos de uso de registro e notificação

• Há eventos externos que devem ser notificados ao sistema?

o Sim => deve haver casos para que os atores possam notificar o sistema

4.3 ELEMENTO ATORES

Representam papéis desempenhados por usuários ou qualquer outra entidade externa ao sistema, por exemplo, hardware e outros sistemas. Podem iniciar casos de uso; podem prover e/ou receber informações dos casos de uso.

Gerente Contas Receber Scanner

FIGURA 22 – REPRESENTAÇÃO DE ATORES

FONTE: Tacla (2010)


29

4.4.1 Descrição

5 FLUXO DE EVENTOS

Um fluxo de evento serve para descrever como o sistema e os atores cooperam entre si para entregar algo de valor aos atores e também descrevem o que pode impedir que isso aconteça. Na verdade, um fluxo de eventos faz a descrição de um caminho entre muitos, uma vez que um caso de uso pode ser representado e executado de formas distintas (TACLA, 2010).

Ainda segundo o mesmo autor, existem fluxos distintos: fluxos primários ou básicos e fluxo alternativo. Por esta visão, o fluxo básico se torna a explicação, enquanto que o fluxo alternativo é a alternativa. Tomemos como exemplo a situação proposta pelo autor citado onde uma pessoa explica um caminho para outra.

Há fluxos primários ou básicos (fluxo normal de eventos) e alternativos (o que fazer se…). Para descrevê-los, é possível se inspirar na situação em que uma pessoa explica um caminho a outra.

“Para ir ao churrasco, pegue a BR-116 na direção de São Paulo. Logo após o Clube Santa Mônica, tem um retorno por baixo da pista. Faça o retorno e continue reto (não retorne à BR). Continue nesta estradinha asfaltada por 1 km, no entroncamento pegue a estrada de terra à direita, ande cerca de 500m, você verá um grande eucalipto

A UML não apresenta uma descrição padrão para casos de uso, sendo composta por diagramas informais. Vale lembrar que os diagramas de caso de uso facilitam a visualização, mas não são descritos detalhadamente, sendo que o uso deste diagrama apenas não é considerado suficiente para a compreensão e modelagem total da situação (TACLA, 2010, p. 17).

De acordo com o autor, os casos de uso são facilmente descritos quando utilizados os seguintes elementos:

• Nome• Descrição• Requisitos (requirements): são os requisitos funcionais providos pelo caso de uso• Restrições (constraints), tais como pré e pós-condições e condições invariantes:

o Precondições: “define o que deve ser verdadeiro para que o caso de uso seja iniciado. Por exemplo, num sistema bancário, para o caso de uso Abrir conta corrente, uma precondição é apresentar CPF sem restrições (aprovação do pedido)” (TACLA, 2010, p. 17).

o Pós-condições: “o que se torna verdadeiro pela execução do caso de uso. No mesmo caso de uso acima, o sistema pode se encontrar em um dos seguintes estados: conta aberta e com um depósito inicial ou conta não aberta por reprovação do CPF” (TACLA, 2010, p. 17).


30

e uma araucária. A entrada da chácara é entre os dois. Não se esqueça de trazer o pinhão” (TACLA, 2010, p. 18) // EXEMPLO DE FLUXO PRIMÁRIO

“Se estiver chovendo muito, os 500m na terra podem ser bem difíceis, porque o barro é mole. Neste caso, siga reto no entroncamento (ao invés de virar à direita) e na próxima à direita pegue a rua de paralelepípedos. Ande cerca de 1 km e depois vire na segunda à direita que vai desembocar na frente da chácara” (TACLA, 2010, p. 18) // EXEMPLO DE FLUXO ALTERNATIVO 1

“Se você for comprar o pinhão no caminho, logo depois de fazer o retorno da BR tem uma venda. Se estiver fechada, um pouco mais à frente tem um senhor da Chácara Pinhais que também vende. Se não encontrar pinhão, não tem problema” (TACLA, 2010, p. 18) // EXEMPLO DE FLUXO ALTERNATIVO 2

Tacla (2010) sugere que nas fases iniciais de análise dos dados é importante manter o foco nos fluxos básicos, pois 80% do tempo de execução de um sistema são ocupados por casos primários. Mas não devemos nos esquecer de documentar os fluxos alternativos, uma vez que ambos documentam como as responsabilidades especificadas nos casos de uso são divididas entre sistema e atores.

“No desenrolar do projeto, as responsabilidades atribuídas ao sistema devem ser distribuídas entre os objetos que compõem o sistema” (TACLA, 2010, p. 19).

IMPORTANTE

5.1 FLUXO BÁSICO

Um fluxo básico demonstra o que acontece quando se executa o caso de uso. Para que isso seja possível, o mesmo deve conter o ator e o evento disparado para dar início ao caso; a iteração entre o ator e o sistema e a descrição de como o caso é finalizado.

5.2 SUBFLUXO

Para melhor entendimento de um fluxo, este pode ser fragmentado em vários subfluxos.

NOTA


31

“Um fluxo de eventos pode ser decomposto em subfluxos para melhorar a legibilidade. Importante evitar muitas decomposições para não dificultar o entendimento. Os subfluxos devem ser executados na totalidade, não podem ser executados pela metade” (TACLA, 2010, p. 19).

5.2.1 Pontos de extensão

São pontos específicos do fluxo que permitem inserir comportamentos adicionais. Podem ser privados ou públicos (TACLA, 2010, p. 20).

Privados: caso sejam visíveis somente dentro do caso de uso onde foram criados.Públicos: quando estendem o caso onde foram definidos.

NOTA

No exemplo Buscar produtos e fazer pedido, os pontos de extensão seguintes são encontrados (TACLA, 2010, p. 20):

_ {Mostrar catálogo de produtos}_ {Escolher produto}_ {Produto esgotado}_ {Processar pedido}_ {Informações de pagamento não válidas}_ {Informações de envio não válidas}

Um ponto de extensão pode definir:

• uma localização única dentro do fluxo, por exemplo, {Mostrar catálogo de produtos}, {Escolher produtos} e {Processar pedido};

• um conjunto de localizações que representam um certo estado do caso de uso, por exemplo, {Produto esgotado} que poderia aparecer em vários pontos do fluxo de eventos;

• uma região entre dois pontos de extensão, por exemplo, {Escolher produtos} e {Processar pedido} (TACLA, 2010, p. 20).

5.3 FLUXO ALTERNATIVO

“Um fluxo alternativo apresenta um comportamento opcional, de outra forma, que não é parte do comportamento normal de um caso de uso” (TACLA, 2010, p. 21). Fluxos alternativos são fluxos que podem ser executados numa funcionalidade a partir de escolha do usuário, e não de erros do sistema. São três tipos de fluxos alternativos:


32

6 ELEMENTO RELAÇÕES

São várias as relações em Casos de Uso, mas as mesmas não representam a ordem de execução dos casos. E as mesmas devem melhorar a compreensão daquilo que o sistema deve executar.

6.1 ASSOCIAÇÃO

Associação é a mais comum das relações. Pode ser percebida entre dois atores ou entre um ator e um caso de uso. São representadas por uma linha cheia, com ou sem direção.

6.2 ATOR X ATORRelações associativas podem conectar atores para representar comunicação entre atores. A relação pode receber um nome que identifica o conteúdo da mensagem, documento ou objeto que trafega entre os atores. A figura mostra uma associação entre o ator usuário de biblioteca que passa o livro ao atendente que realiza o empréstimo ou a devolução. Como não há flechas, assume-se que o atendente devolve algo ao usuário da biblioteca, provavelmente um comprovante não representado no diagrama. Não é recomendável colocar este tipo de relação no diagrama de casos de uso (TACLA, 2010, p. 22).

FIGURA 23 – REPRESENTAÇÃO DE RELAÇÕES EM CASOS DE USO

Usuário Biblioteca Atendente

livroRealizar Empréstimo

Realizar Devolução

FONTE: Tacla (2010)

6.3 ATOR X CASO

Associações entre atores e casos de uso servem para indicar se quem dá início à comunicação é o ator ou o caso de uso, além de traçar o fluxo da informação, indicando quem alimenta quem com a informação.

• Específico: iniciam num ponto de extensão.• Regional: podem ocorrer entre dois pontos de extensão.• Geral: podem ocorrer em qualquer ponto do caso de uso.


33

6.4 ELEMENTO DEPENDÊNCIA - INCLUSÃO E EXTENSÃO

Quando um caso de uso inclui outro caso de uso (considerado um subcaso) na sua execução, este está usando a relação de inclusão entre casos de uso. Um subcaso pode ser considerado como um subfluxo de um fluxo de eventos primário, que foi separado e deve ser executado por completo. A Figura 24 mostra:

Um caso onde se efetua uma matrícula que possui subfluxos escolher disciplinas, alocar alunos às turmas e emitir boleto. Este último é compartilhado com o caso Efetuar inscrição curso opcional e, portanto, deve ser representado no diagrama. Um erro comum que adiciona complexidade ao diagrama é incluir os subfluxos escolher disciplinas e alocar alunos às turmas no diagrama (TACLA, 2010, p. 22).

FIGURA 24 – RELAÇÃO DE INCLUSÃO

Aluno

Efetuar inscrição Curso Opcional

Alocar Alunos as Turmas

Escolher Disciplinas

Efetuar Matrícula

Emitir Boleto

<<Include>>

<<Include>>

<<Include>><<Include>>

FONTE: Tacla (2010)

A inclusão deve ser utilizada para administrar comportamentos comuns e não para estruturar funcionalmente o diagrama.

NOTA


34

7 EXTENSÃO

É uma indicação de que outros casos de uso poderão ser adicionados a um caso de uso específi co. Para Tacla (2010, p. 25):

• Um caso de uso de extensão não requer modifi cações no caso base (aquele que é estendido). O comportamento básico do caso base permanece intacto. Um caso de uso que estende um caso base conhece este último (não é muito comum um caso de uso estender mais de um caso base).• Uma extensão nasce como um fl uxo alternativo, mas nem todo fl uxo alternativo vira uma extensão.• vCasos de uso que estendem assumem o controle no ponto de extensão e quando terminam devolvem o controle no mesmo ponto.

Pelo exemplo proposto na Figura 25, “a emissão de histórico escolar é estendida pelo caso imprimir comprovante de término quando o aluno solicitante for formado. Observa-se que é um comportamento opcional que pode não ser oferecido sem prejuízo ao comportamento básico emitir histórico escolar” (TACLA, 2010, p. 26).

FIGURA 25 – EXEMPLO DE EXTENSÃO

Aluno

Imprimir Comprovante Termino

aluno formado e umponto de extensão

Emitir Historico Escolar

aluno formadovalues

<<extend>>

FONTE: Tacla (2010)

Nota-se no ponto de extensão público denominado {aluno formado} onde o comportamento opcional imprimir comprovante término é inserido. É provável que existam outros pontos de extensão privados defi nidos nos fl uxos de emitir histórico escolar, porém, no diagrama só os usados pelas extensões são listados (TACLA, 2010, p. 26).

8 ELEMENTO GENERALIZAÇÃO/ESPECIALIZAÇÃO

A relação de generalização/especialização pode ocorrer entre casos de uso ou entre atores.

Caso x Caso


35

Generalização permite especificar comportamentos genéricos que podem ser especializados para atender necessidades específicas. Normalmente é utilizado quando se quer descrever famílias de sistemas. Por exemplo, uma empresa que desenvolve software para terminais bancários de autoatendimento quer expandir seus negócios para outras áreas, tais como pagamento direto em bombas de gasolina.

NOME: Realizar transação (caso abstrato).DESCRIÇÃO: Permite ao usuário comprar mercadorias de um terminal automático, sendo o valor das mercadorias descontado de uma conta bancária.PRECONDIÇÕES: (e) O cliente possui um cartão bancário; a conexão com o banco está ativa; o terminal deve ter mercadoria.PÓS-CONDIÇÕES: (ou) O terminal retornou o cartão bancário ao cliente, entregou a mercadoria ao cliente e debitou o valor de sua conta. O terminal retornou o cartão bancário ao cliente, não entregou nenhuma mercadoria e nenhum valor foi debitado da sua conta.

FONTE: Disponível em: <https://www.passeidireto.com/arquivo/6299813/analise-e-projeto-oo-e-uml/8>. Acesso em: nov. 2015.

Ator x Ator

Especialização de atores representa que um conjunto deles possui responsabilidades ou características em comum. Algumas dicas para evitar modelagens desnecessárias:

• Não utilizar atores para representar permissões de acesso.• Não utilizar atores para representar organogramas (hierarquias) de cargos

de uma empresa.• Utilizar atores somente para definir papéis em relação ao sistema.

Por exemplo, se num sistema de matrículas de uma universidade há casos de usos especiais para alunos de ciências exatas e para alunos de humanas, então é sinal de que estes alunos são especializações de um ator genérico aluno. A Figura 26 ilustra a notação UML para este caso. Observar que alunos de ciências exatas e de humanas herdam todas as associações do ator aluno.



36


Aluno

Aluno C. Extas Aluno HumanasFONTE: Tacla (2010)

9 DICAS IMPORTANTES

Casos de uso auxiliares

“Casos de uso auxiliares são frequentemente esquecidos, pois não são essenciais à funcionalidade do sistema. Porém, esquecê-los completamente pode conduzir a um sistema difícil de ser utilizado” (TACLA, 2010, p. 27).

“Lembrar de colocar casos de uso para executar, manter e configurar o sistema, tais como: lançar e parar o sistema, incluir novos usuários, fazer backup das informações, incluir novos relatórios e realizar configurações” (TACLA, 2010, p. 27).

Decomposição funcional

Tacla (2010, p. 28) explica a decomposição funcional desta forma:

• Não é necessário detalhar em excesso os casos de uso. Muitos detalhes levam à decomposição dos casos em funções. O objetivo é compreender o sistema através de cenários de utilização.• Casos de uso não são feitos para analisar (no sentido de decompor) os requisitos em requisitos menores. É um processo de síntese ou elaboração (e não de análise) no qual o problema não é totalmente conhecido. Quebrá-lo em partes menores (análise) dificulta a obtenção de uma visão geral.• Em equipes com forte competência em análise estruturada, há tendência em encontrar funções ao invés de casos de uso. Por exemplo, fazer pedido, revisar pedido, cancelar pedido e atender pedido podem parecer bons casos de uso. No fundo, todas estas funções estão relacionadas ao caso de uso realizar pedido.• Decomposição funcional pode levar a um número intratável de casos, mesmo para pequenos sistemas, e à perda de foco no que realmente é importante no sistema (o que traz valor aos atores). • Casos de uso não chamam outros casos de uso ou se comunicam com outros casos.


37

Estrutura e detalhamento

Ainda de acordo com Tacla (2010, p. 30):

• Não estruturar demais o diagrama de casos de uso, isto é, não inclua relações entre casos de uso a não ser que sejam extremamente necessárias. O uso em excesso destas relações pode fragmentar o diagrama, diminuindo a compreensão global.• O modelo deve ser o mais simples e direto possível.• Não descrever o que ocorre fora do sistema. Por exemplo, interação entre atores pode ser importante para o negócio, mas se o sistema não facilita esta interação, deixe-a fora. Se for necessário esclarecer estes pontos, faça um modelo do negócio e não um modelo de casos de uso.• Não fazer casos tais como incluir, consultar, alterar e excluir (ICAE). Casos de uso que descrevem comportamentos ICAE não adicionam muito valor à descrição da funcionalidade do sistema. Para estes tipos de comportamentos, os requisitos são bastante claros e não se deve perder tempo especificando-os.

Modelo de casos de uso é mais que um diagrama

O diagrama de casos de uso é uma visão panorâmica dos casos de uso e, portanto, apenas um dos componentes do modelo de casos de uso. A descrição textual dos mesmos é a parte mais importante do modelo. São elementos do modelo de casos de uso: glossário, modelo do domínio e diagramas de atividades.

Um glossário e um modelo do domínio podem evitar o excesso de

detalhes nas descrições dos casos de uso. Por exemplo, ao invés de descrever a validação da entrada de dados, os campos podem ser definidos no glossário com os respectivos valores possíveis.

Um modelo do domínio ajuda a entender as relações existentes entre as entidades do domínio e as restrições sobre as relações.



38

Passos

Para elaborar um modelo de casos de uso, os seguintes passos podem ser seguidos (TACLA, 2010, p. 35):

• Recapitular a visão do sistema (estudo de viabilidade) aos envolvidos.• Elaborar, se necessário, um diagrama de contexto para definir os limites do sistema (o que está dentro e o que está fora).• Identificar os atores do sistema.• Identificar os casos de uso: descrevê-los e rascunhar o fluxo de eventos. Não se preocupe com fluxos alternativos. Não gaste mais do que 10 minutos para descrever cada caso de uso.• Esboçar o diagrama de casos de uso mostrando associações entre atores e casos de uso.• Verificar os casos de uso.• Há casos de uso sem conexão com requisitos funcionais? Caso haja, pode haver casos em excesso ou requisitos que não foram identificados!• Há requisitos funcionais sem casos? Alguns casos podem ter sido esquecidos.• Todos os requisitos não funcionais foram tratados (associados aos casos de uso quando são específicos)?• Todos os tipos de usuários foram mapeados para um ator ao menos?• Descrever os casos detalhadamente.• Representar os subfluxos (<<include>>) e fluxos alternativos (<<extend>>) considerados importantes no diagrama.• É possível eliminar os casos incluídos ou as extensões e ainda ser capaz de entender o que o sistema faz para as partes interessadas?

39

RESUMO DO TÓPICO 2

Neste tópico você viu que:

• Todos os diagramas da UML são úteis para análise de aspectos importantes do desenvolvimento de software, mas não é necessário aplicar todos os diagramas em um mesmo projeto. Escolha apenas aqueles que o ajudarão a entender melhor o sistema que está desenvolvendo e a deixar mais claras as soluções que irá implementar.

• Não deve deixar que os diagramas fiquem grandes e complexos demais.

• Se perceber que isso está acontecendo, tente separá-los em mais de um, dividindo suas funcionalidades.

• Normalmente, todos os diagramas são desenvolvidos com auxílio de um software.

• Diagrama de casos de uso é um diagrama que mostra um conjunto de casos de uso, atores e seus relacionamentos. Abrange a visão estática de caso de uso de um sistema, ele é criado após o levantamento dos requisitos da solução imaginada, cada caso de uso é um de seus requisitos funcionais.

• Este diagrama permite visualizar os limites do sistema, sua relação com os demais sistemas, com seus componentes internos e as funções que deve realizar.

40

1 Explique a utilidade do diagrama de casos de uso para os testes do sistema.

2 Explique a utilidade do diagrama de casos de uso para criação dos manuais do usuário.

3 Construa um modelo de casos de uso para a seguinte situação fictícia: “Estamos criando um serviço de entregas. Nossos clientes podem nos requisitar a entrega de volumes. Alguns volumes são considerados de maior valor por nossos clientes, e, portanto, eles querem ter tais volumes segurados durante o transporte. Contratamos uma companhia de seguro para segurar volumes de valor”.

FONTE: Disponível em: <http://ebrito.com.br/profa-elaine/ExGabarito.pdf>. Acesso em: 20 out. 2015.

4 Qual é a notação da UML para um caso de uso? Qual é a notação da UML para um ator? Qual a notação utilizada na UML para o relacionamento de generalização entre casos de uso?


5 Defina o que significa um ator. O que significa um ator estar associado a um caso de uso por um relacionamento de comunicação?


6 Qual o objetivo dos casos de uso?

7 Considere a seguinte declaração obtida de um gerente de uma empresa que comercializa livros por correio durante o levantamento de requisitos para construção de um sistema de software: “Após a ordem de compra do cliente ter sido registrada, o vendedor envia uma requisição ao depósito com detalhes da ordem de compra”. Quais atores em potencial podem ser identificados a partir desse texto?


AUTOATIVIDADE

41

8 Em uma empresa, vários projetos são realizados. Os 50 empregados da empresa trabalham em pelos menos um projeto. Há um sistema implantado na empresa que permite aos participantes de um determinado projeto marcarem suas horas de trabalho. Esse sistema também permite que outra pessoa, ao fim do mês, gere os relatórios com os totais de horas trabalhadas de cada participante. Quantos atores você definiria para esse sistema?


9 Suponha que um sistema de vendas deve gerar de forma automática um conjunto de estatísticas para a diretoria da empresa no último dia útil de cada mês. Desenhe o diagrama de casos de uso para essa situação.


43

TÓPICO 3

DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE

ESTADOS

UNIDADE 1

1 INTRODUÇÃO

O diagrama de atividades é um gráfico de fluxo e mostra basicamente o fluxo de controle de uma atividade para outra, sendo utilizado para modelar o comportamento dos processos. É um dos diagramas que mais sofreu alterações desde o surgimento da UML, e abrange a visão dinâmica da UML (modela situações que sofrem mudanças no sistema). Neste diagrama, uma atividade é modelada através de uma sequência estruturada de ações sendo controladas, na maioria das vezes, por nós de decisão.

Veja na Figura 27 o exemplo do diagrama de atividades gerado pelo caso de uso Registrar compra produtos, proposto por Piva (2010).

44


FIGURA 27 – DIAGRAMA DE ATIVIDADES

Funcionário Sistema

Verifi carLogin,Senha

Logar nosistema

Solicitarcartão do

Cliente

Verifi carExistênciado Produto

Verifi carCartão do

Cliente

Verifi carSaldo doProduto

Funcionário

Cartão

Produto

ItemCompra

Passarcódigo daBarra docartão do

cliente

Passarcódigo daBarra doProduto

Digitar aquantidadecompradado Produto

Terminarregistro do

Produto

Atualizartotal da

empresa CriarCompra

Compra

login inválido

login válido

cartão inválido

cartão válido

não existe

existe

não possui saldo sufi ciente

possui saldo sufi cientenão existe

existe

Diagrama de atividadesdo caso de uso Registrarcompra produtos.

FONTE: Piva (2010)

O diagrama de atividades apresenta de forma simples e clara as ações que são executadas em cada caso de uso. Este tipo de diagrama deve ser dividido com linhas verticais para identifi car o executor da ação.

TÓPICO 3 | DIAGRAMA DE ATIVIDADES E DIAGRAMA DE MÁQUINA DE ESTADOS

45

2 AÇÃO

Uma ação é uma ação que não pode ser decomposta dentro de uma atividade. Já uma atividade é representada por ações ou subatividades. Uma ação não inicia sua execução até que todas as suas condições de entrada sejam satisfeitas. Somente quando uma ação é terminada é que a ação subsequente fica habilitada.


Ações também podem ser entendidas como precondições, que irão definir condições necessárias para que uma ação possa ser executada, e também pós-condições que vão definir o estado depois que a ação for executada.

NOTA

3 ATIVIDADES

Atividades podem ser representadas por sequências de ações e também de subatividades. Dessa forma, para representar uma subatividade dentro de uma atividade (ou seja, todo um conjunto de ações ou subatividades), utiliza-se uma representação semelhante à de uma ação, com um pequeno ícone no canto direito inferior. Disponível em: <www.dca.fee.unicamp.br/~gudwin/ftp/ea976/AtEst.pdf>. Acesso em: nov. 2015.

4 EVENTOS

São situações onde ocorrem mudanças de estado de forma muito rápidas e estabelecem o início de outra ação.

5 NÓS DE CONTROLE

Nós de controle existem para controlar o fluxo dos processos e os dados entre as ações.

6 PONTOS DE EXTENSÃO

Evitam que o diagrama fique muito poluído, pois permitem a partição das ações.

46


FIGURA 28 – EXTENSÕES

Sistema natela principal

Seleciona Opção"Pagamento de

Contas "

Selecionaopção

Solicitacancelamento

InsereDados

Clica OK

Selecionaopção

Solicitacancelamento

Inserepassword

Fecha tela depagamentode contas

Fecha telade password

Efetuapagamento

da conta

Verifi capassword

Limpa telade password

Abre Janelade password

Abre Janela"Pagamentode Contas"

[opção = cancela]

Usuário Sistema

[opção - continua][result - correto]

[result - incorreto]

[opção = continua]

[opção - cancela]

FONTE: Piva (2010)

Diagramas de atividade como os da fi gura são utilizados para detalhar os casos de uso levantados durante a especifi cação do sistema. Nesses diagramas, assume-se que o usuário do sistema realiza certas ações e o sistema, em resposta, reage realizando certas tarefas. Com isso, o comportamento do sistema pode ser especifi cado (PIVA, 2010, p. 191).


47

7 OUTROS RECURSOS EM DIAGRAMAS DE ATIVIDADES

Os diagramas de atividades possuem ainda, de acordo com a versão 2.3 da norma UML, outros recursos não apresentados aqui neste texto, que podem elevar sobremaneira a complexidade do diagrama. Dentre eles, o recurso de regiões de expansão, os pinos de entrada e saída, os nós estruturados, os conjuntos de parâmetros e outros podem ser consultados diretamente no texto da norma.

Um diagrama de atividades mostra um processo de negócios ou um software como um fluxo de trabalho por meio de uma série de ações. Computadores, componentes de software ou as pessoas podem executar essas ações.

Você pode usar um diagrama de atividades para descrever processos de diversos tipos, como os exemplos a seguir:

Um processo de negócios ou um fluxo de trabalho entre usuários e seu sistema. Para obter mais informações, consulte Requisitos de usuário do modelo.

As etapas executadas em um caso de uso. Para obter mais informações, consulte Diagramas de caso de uso UML: diretrizes.

Um protocolo de software, ou seja, as sequências permitidas de interações entre os componentes.

Um algoritmo de software.

FONTE: Disponível em: <https://msdn.microsoft.com/pt-br/library/dd409360.aspx>. Acesso em: 30 set. 2015.

8 RELAÇÃO COM OUTROS DIAGRAMAS

Se você desenhar um diagrama de atividades para descrever um processo comercial ou uma forma em que os usuários poderão usar seu sistema, você pode desenhar um diagrama de caso de uso para mostrar uma exibição diferente das mesmas informações. No diagrama de caso de uso você pode desenhar as ações dos casos de uso. Dê aos casos de uso os mesmos nomes que as ações correspondentes. As vantagens da exibição de caso de uso é que você pode:

• Mostrar em um diagrama como maiores ações/casos de uso são compostos de pequenos, usando a relação inclui.

• Conecte cada caso de uso/ação explicitamente para os usuários ou sistemas externos envolvidos em sua execução.

• Desenhe limites em torno de ações/casos de uso com suporte pelo seu sistema ou cada componente principal.

48


Você também pode desenhar um diagrama de atividades para descrever o design detalhado de uma operação de software.

Em um diagrama de atividades você pode mostrar o fluxo de dados passados entre ações. Consulte descrevendo o fluxo de dados. Mas um diagrama de atividades não descreve a estrutura dos dados. Para essa finalidade, você pode desenhar um diagrama de classe UML.

Para modelar processos/atividades, a UML (Unified Modeling Language) sugere a utilização do Diagrama de Atividades, que descreve os passos a serem percorridos para a conclusão de uma determinada situação.

FONTE: Disponível em: <http://www.purainfo.com.br/artigos/uml-diagrama-de-atividades/>. Acesso em: 30 set. 2015.

Para fluxos simples: Você pode demonstrar uma sequência de atividades com tomada de decisão, como, por exemplo:

FIGURA 29 – FLUXOS SIMPLES

Receber nº da conta

Emitir mensagemde conta válida

Emitir mensagemde conta válidaConta existe?

Pesquisar conta

Início1

2

3 4

5Fim

(Não)

(Sim)

FONTE: Piva (2010)

9 EXEMPLO DE CRIAÇÃO DE DIAGRAMA DE ATIVIDADES

Exemplo 1: Considere o fluxo de trabalho associado à construção de uma casa. Primeiro, você seleciona um local. A seguir, contrata um arquiteto para projetar sua casa. Uma vez definida a planta, seu desenvolvedor


49

determina os custos da casa. Após concordar com um preço e com uma forma de pagamento, a construção pode começar. As licenças são tiradas, o terreno é cavado, a fundação é cimentada, as estruturas são erguidas e assim por diante, até tudo fi car pronto. Você então recebe as chaves e um certifi cado de “habite-se” e toma posse da casa. Embora seja uma grande simplifi cação do que realmente acontece em um processo de construção, essa descrição capta o percurso crítico do fl uxo de trabalho correspondente.


FIGURA 30 – DIAGRAMA DE ATIVIDADES

Construir construção Certifi cadoDeHabitse[Concluído]

[rejeitado]

[else] Bifurcação concorrente

Fluxo de objetos

Selecionar local

Estado inicial

Contratar arquiteto

Desenvolver plano

Orçar plano

Estado de Ação

Fazer trabalho no local Fazer trabalho comoutros setores

Estado fi nal

Estado da atividadecom submáquina

União concorrente


50


Características:

• Um diagrama de atividades é essencialmente um fluxograma que dá ênfase à atividade que ocorre ao longo do tempo.

• Você pode considerar um diagrama de atividades como um diagrama de sequência cujo interior é revelado.

• Um diagrama de sequência observa os objetos que passam mensagens.• Um diagrama de atividades observa as operações passadas entre os objetos.• Mostra o fluxo de uma atividade para outra.• Uma atividade é uma execução em andamento.• As atividades resultam em uma ação.• As ações abrangem a chamada a outras operações, enviando um sinal,

criando ou destruindo um objeto.

Exemplo 2: O diagrama a seguir mostra um diagrama de atividades para uma empresa de varejo, que especifica o fluxo de trabalho envolvido quando um cliente devolve um item de um pedido postal. O trabalho começa com a ação solicitar devolução do cliente e depois flui por televendas (receber número de devolução), retorna ao cliente (enviar item) e, a seguir, ao depósito (receber item e depois Incluir item novamente no estoque) e, por fim, terminando em contabilidade (creditar conta). Conforme o diagrama indica, um objeto significativo (i, uma instância de Item) também acompanha o fluxo do processo, mudando do estado devolvido para o estado disponível.

FONTE: Disponível em: <www.purainfo.com.br/artigos/uml-diagrama-de-atividades>. Acesso em: 29 set. 2015.


51

FIGURA 31 – EXEMPLO 2 – DIAGRAMA DE ATIVIDADES

Informa novocódigo do Cliente

Verifica se ocliente já existe

Exibe mensagemao usuário

Informa os dadosdo novo cliente

Salva dadosdo cliente

[Cliente já existe]

[Cliente Não existe]

FONTE: Disponível em: <www.purainfo.com.br/artigos/uml-diagrama-de-atividades>. Acesso em: 10 set. 2015.

Diagrama de máquina de estados: Esboça a visão dinâmica de um sistema (TACLA, 2010).

Principais componentes: estado, evento.

Esse diagrama mostra os estados que podem ser assumidos por um objeto em seu ciclo de vida. Geralmente o utilizamos para entender como tais mudanças acontecem, de modo a podermos definir as trocas de mensagens e os métodos que as controlam. O início da transição é representado por um círculo preenchido, e o final por um círculo preenchido, porém com um aro pintado de branco (PIVA, 2010, p. 193).

Utilizando o exemplo proposto pelo autor, atentemos para a situação da classe Produto da padaria do senhor João, que pode assumir três estados diferentes: 1 Ativo, 2 Ponto de encomenda e 3 Em falta. Esses valores são aplicados ao atributo situação quando a execução do caso de uso Registrar pagamento compra ou do caso de uso Registrar entrada de produtos.

52


FIGURA 32 - EXEMPLO DE DIAGRAMA DE MÁQUINA DE ESTADOS

Produto

Variação do atributo situação

recebeProduto( )

recebeProduto( )

recebeProduto( )

pagaCompra( )

pagaCompra( )

quantidadeEstoque+quantidadeEntrada>pontoEncomenda

quantidadeEstoque+quantidadeEntrada>pontoEncomenda

quantidadeEstoque<=pontoEncomenda

quantidadeEstoque<=pontoEncomenda

quantidadeEstoque - - 0

Ativo(I)

Em falta (3)

Ponto de encomenda (2)

FONTE: Piva (2010)

Pelo diagrama podemos perceber que, através de um estado ativo, o produto poderá mudar sua situação para “ENCOMENDA” ou “EM FALTA”, dependendo das suas saídas, sendo que a regra estabelecida para a situação de encomenda é seu saldo ser menor que o indicado para este campo. Observe também que somente os métodos pagarCompra e receberProduto alteram o estado do produto e que a baixa do estoque só se concretiza quando o pagamento da compra é efetivado (PIVA, 2010, p. 194).


53

LEITURA COMPLEMENTAR

Usando a modelagem colaborativa no aprendizado da UML

Mauro C. Pichiliani1, Celso M. Hirata1 1Divisão de Ciência da Computação – Instituto Tecnológico de

Aeronáutica (ITA) Caixa Postal 12.228-900 - São José dos Campos - SP

{pichilia, hirata}@ita.br

Abstract. The design is an important task in the object-oriented software development. Collaborative tools has been considered to be used in software development, however little effort has been made in the assessment of usage of these tools for both productivity verification and ef ectiveness of collaborative learning. For the assessment of the effectiveness of collaborative learning, it is required the data collection for analysis. This article describes a study of data collection for the assessment of the effectiveness of learning of students groups where a collaborative tool was used to assist the learning of UML.

Resumo. O projeto é uma tarefa importante no desenvolvimento de software orientado a objetos. Ferramentas colaborativas têm sido consideradas para serem utilizadas no desenvolvimento de software, contudo, pouco esforço tem sido feito na avaliação do uso dessas ferramentas tanto para a verificação de produtividade quanto para a eficácia do aprendizado colaborativo. Para avaliação da eficácia do aprendizado colaborativo existe uma necessidade de obtenção de dados para a análise. O presente artigo descreve um estudo da coleta de dados para a avaliação da eficácia do aprendizado de grupos de alunos onde uma ferramenta colaborativa foi empregada para auxiliar o aprendizado da UML.

1 INTRODUÇÃO

A área de Informática na Escola tem evoluído muito nessa década, principalmente pelo uso de ferramentas de groupware pedagógicas que exploram o uso de colaboração no aprendizado. De acordo com Stahl [STAHL, 2002], o uso de ferramentas de groupware na escola pode facilitar, dentre outras habilidades, o aprendizado colaborativo e a construção do conhecimento. Contudo, pouco esforço tem sido feito no sentido de avaliar quantitativamente a eficácia e produtividade do aprendizado dos alunos que utilizaram ferramentas colaborativas como instrumento pedagógico.

Uma das maneiras de acompanhar a evolução do aprendizado de alunos que utilizam ferramentas colaborativas no aprendizado é analisar o aproveitamento dos estudantes por meio do histórico das interações dos alunos entre si e com o ambiente. O objetivo deste artigo é propor o uso de coleta de dados e uma alternativa de avaliação do aprendizado de grupos de alunos


54

quando uma ferramenta colaborativa é empregada como instrumento pedagógico no aprendizado da UML (Unified Modeling Language) (BOOCH, 1998), por meio da análise do histórico das interações geradas durante o aprendizado. Neste contexto, este artigo apresenta uma análise das variáveis de coleta de dados do aprendizado de grupos de alunos em um experimento controlado.

A partir desta análise dos dados coletados, o professor poderá dispor de um acompanhamento mais preciso do que o grupo realmente está aprendendo, assim como uma visão geral do processo ensino-aprendizagem. Este artigo está dividido em cinco seções.

A Seção 2 descreve uma visão geral dos aspectos funcionais das ferramentas colaborativas e algumas abordagens de avaliação disponíveis na literatura. Na Seção 3 apresentam-se detalhes do grupo de alunos e do experimento realizado. Na Seção 4 apresenta-se uma alternativa de avaliação da eficácia de aprendizado dos grupos usando informações coletadas durante o uso da ferramenta colaborativa. Por fim, na Seção 5 são apresentadas algumas considerações finais.

2 FERRAMENTAS COLABORATIVAS

Uma ferramenta colaborativa que será empregada para auxiliar o ensino de algum conteúdo deve levar em consideração alguns aspectos funcionais para poder suportar a colaboração. Santoro et al. (2002) citam como principais aspectos funcionais a comunicação, a coordenação, a percepção (awareness), o compartilhamento de informações e a designação de papéis. A comunicação é de extrema importância em situações de trabalho em grupo, seja ela utilizada para trocar ideias, discutir, aprender, negociar ou para tomar decisões.

A comunicação pode ser classificada em síncrona ou assíncrona, dependendo do momento no qual os membros receberam as mensagens enviadas pelo canal de comunicação. Diferentes canais de comunicação podem ser utilizados para tornar a comunicação mais eficiente e produtiva, como, por exemplo, chat ou audioconferência. Outra maneira de classificar a comunicação diz respeito à existência de ligações entre os participantes, através tanto de canais de comunicação direta, como troca de mensagens e reuniões, quanto por meio de um canal indireto através da memória de grupo, onde a construção e o compartilhamento do conhecimento comum podem ser considerados interfaces de comunicação.

A coordenação do grupo que trabalha com uma ferramenta colaborativa síncrona pode exigir um sofisticado mecanismo de controle das ações para garantir o sucesso da colaboração. Mecanismos de controle de concorrência, como travas ou transformação operacional, são utilizados para garantir a consistência dos elementos que estão sendo manipulados pelos participantes da colaboração no documento compartilhado. Em situações onde a probabilidade de conflitos entre os usuários for baixa ou existir um moderador para coordenar as ações dos usuários, o controle de concorrência pode ser dispensado. Nestas


55

situações, a coordenação das ações pode ficar a cargo do chamado protocolo social, caracterizado pela ausência de mecanismos de controle explícitos entre as atividades e pela confiança nas habilidades dos participantes de mediar por si só as interações por meio de um canal de comunicação. Durante o trabalho em grupo a percepção representa grande importância e apresenta relacionamento com coordenação, comunicação e cooperação.

Nas ferramentas colaborativas síncronas a percepção permite que um participante fisicamente separado esteja ciente da presença e das ações dos demais participantes da colaboração, facilitando o aprendizado em conjunto. A percepção também permite socializar virtualmente o ambiente e pode servir para indicar o esforço dos participantes em interagir com a ferramenta e com os demais participantes. A percepção, em geral, é implementada nas ferramentas colaborativas síncronas por meio de elementos de percepção que fornecem informações imediatas a respeito do estado dos participantes na colaboração e de suas interações com a ferramenta.

Os elementos de percepção, apesar de vantajosos, não conseguem se aproximar da riqueza de informações proporcionadas pela interação face a face (SANTORO et al., 2002). A colaboração necessita que os participantes compartilhem informações a este aspecto, é essencial para os grupos devido à necessidade de prevenir esforços repetitivos e assegurar que todos os participantes do grupo estejam utilizando a mesma informação, de forma que não haja inconsistências. As ferramentas colaborativas geralmente fazem uso de documentos compartilhados, como mecanismo de compartilhamento de informações e de armazenamento da memória do grupo, que deve registrar todo o processo de interação, como a própria comunicação realizada e passos desencadeados, bem como todos os produtos gerados durante a colaboração.

A utilização de papéis predefinidos em ferramentas colaborativas tem como objetivo principal estruturar as interações entre os participantes do grupo, definir tarefas e gerenciar o acesso aos elementos do documento compartilhado. Um papel descreve como um conjunto de indivíduos se relaciona com algum elemento compartilhado e com os outros participantes restantes do grupo por meio da especificação dos direitos e responsabilidades sobre diferentes tarefas dentro do processo de aprendizagem. A definição de papéis também é utilizada como um mecanismo de coordenação das atividades dos participantes, e ainda como um mecanismo de controle de acesso a elementos do documento compartilhado. No entanto, sua atribuição precipitada pode restringir o potencial criativo dos participantes, ou seja, cada indivíduo somente efetuaria as operações específicas de seu papel, sem que todo o seu potencial tenha sido alcançado. Além dos aspectos funcionais, o uso de uma ferramenta colaborativa como instrumento pedagógico deve levar em consideração a metodologia de ensino que está sendo aplicada.

Várias metodologias de ensino já estão adaptadas para o uso de ferramentas colaborativas, e nestas metodologias o principal foco é na realização


56

de tarefas por um grupo de alunos. Dentre essas metodologias, destacam-se: resolução de problemas, estudo de casos e abordagem dos sete passos (PADILHA et al., 2003). Os editores colaborativos CUTE (Collaborative UML Technique Editor) (DIAS e XEXÉO, 1997) e CO2DE (Collaborate to Design) (BORGES et al., 2003) são exemplos de iniciativas que permitem de edição colaborativa de diagramas da UML, assim como as ferramentas CASE (Computer Aided Software Engineering), comerciais Poseidon for UML (GENTLEWARE, 2006) e Magic Draw [No Magic 2006]. O principal objetivo destas ferramentas é o produto final obtido pelas interações dos usuários, ao invés do processo de geração das interações.

Devido a este objetivo, poucos recursos didáticos e pedagógicos foram implementados, tornando o suporte ao processo ensino-aprendizado limitado nestas ferramentas. Várias análises são sugeridas para avaliar a eficácia e o desempenho do aprendizado de alunos em atividades colaborativas. Lund e Baker (1999) analisam as interpretações de professores das interações dos alunos durante a resolução colaborativa de problemas. Padilha et al. (2003) propõem técnicas de Data Mining que detectam regras de associação por meio dos valores de variáveis observadas durante a colaboração. Avouris et al. (2003) descrevem um toolkit genérico para análise e processamento de dados coletados durante atividades de aprendizado colaborativas. Martinez et al. (2003) combinam avaliação qualitativa e análise da rede social para analisar as interações sociais e aspectos de participação no aprendizado colaborativo. Apesar de considerar os dados coletados a partir de experimentos colaborativos, nenhuma das análises citadas faz uso de índices quantitativos para auxiliar a avaliação da eficácia e produtividade do aprendizado colaborativo.

3 EXPERIMENTO REALIZADO

3.1 CONTEXTO DO EXPERIMENTO

O intuito do estudo descrito neste artigo é apresentar ao professor uma análise da eficácia do aprendizado dos grupos de alunos que utilizaram uma ferramenta colaborativa para auxiliar a resolução de problemas. Um experimento controlado foi conduzido para analisar a eficácia do aprendizado de grupos de alunos que utilizaram uma ferramenta colaborativa no aprendizado da modelagem de diagramas da UML. A ferramenta colaborativa escolhida para realizar o experimento descrito neste artigo foi o ArgoUML (2006), que foi adaptada para suportar a edição colaborativa. As adaptações incluem um chat, um editor de diagramas da UML colaborativo e travas como mecanismo de controle de concorrência, além de elementos de percepção remota, como, por exemplo, telepointers e lista de elementos travados. A metodologia de ensino adotada durante o aprendizado dos grupos no experimento foi a resolução de problemas.

Esta metodologia pode constituir tanto um conteúdo educativo como um modo de conceber as atividades educativas. O ensino baseado na resolução de problemas supõe fomentar nos alunos o domínio de procedimentos para dar respostas a situações distintas e mutáveis (POZO, 1998).


57

3.2 AMBIENTE DO EXPERIMENTO

O experimento foi conduzido com o objetivo principal de coletar dados para a análise da eficácia do aprendizado dos grupos de alunos. Este experimento constou da observação tanto das interações e o comportamento dos grupos de alunos, como também do modo no qual a ferramenta forneceu suporte para o processo de elaboração de diagramas desde a ideia conceitual até a versão do diagrama final. Para a realização do experimento, 12 alunos foram divididos, de forma aleatória, em seis pares, sem repetições. Os alunos eram estudantes do curso de pós-graduação com idades entre 23 e 34 anos (média de idade por volta de 26 anos com desvio padrão igual a 2,27, incluindo seis homens e seis mulheres). O experimento foi realizado entre novembro de 2005 e janeiro de 2006.

Os alunos participantes foram divididos em dois conjuntos: no primeiro conjunto, os grupos 1, 2 e 3 utilizaram um chat como canal de comunicação, e no segundo conjunto, os grupos 4, 5 e 6 utilizaram um software de audioconferência para se comunicar. A divisão dos pares de alunos em dois conjuntos tem como objetivo identificar a influência de diferentes canais de comunicação na evolução do aprendizado. O ambiente utilizado no experimento foi composto de duas salas, onde os alunos utilizaram o ArgoUML em suas estações de trabalho, sem nenhum contato visual com seus parceiros. Em cada sala um experimentador observou o comportamento do aluno, enquanto uma câmera de vídeo fez a gravação das expressões faciais e do diálogo entre os alunos.

Cada aluno preencheu um formulário sobre seu perfil antes de iniciar as tarefas que foram monitoradas no experimento. Em seguida, os alunos receberam um documento explicando o cenário fictício e o problema em questão para cada uma das três tarefas a serem completadas no experimento. Os alunos indicaram aos experimentadores quando chegaram a um consenso sobre o término de cada tarefa, para só então responderem a um questionário sobre o esforço requerido pela tarefa completada. Ao término das três tarefas, cada aluno recebeu um questionário de avaliação final e participou de uma breve entrevista com o experimentador. Os principais dados objetivos coletados durante o experimento foram registrados no log interno da ferramenta, que armazenou o histórico da interação dos alunos entre si e com o editor colaborativo.

A gravação em vídeo das expressões faciais e do diálogo entre os alunos, as respostas dos questionários e as observações do experimentador forneceram informações subjetivas sobre o aprendizado.

3.3 VARIÁVEIS OBSERVADAS

A definição das variáveis a serem observadas durante a execução das tarefas teve como base os recursos disponíveis no ambiente colaborativo para a resolução de problemas e nos aspectos que evidenciam a aprendizagem. Na Tabela 1 são apresentadas as variáveis observadas, bem como uma breve descrição do seu significado e seus valores discretos. O valor numérico colocado entre

58


parênteses após o valor discreto da variável foi utilizado para o cálculo do índice de aproveitamento, descrito na próxima seção. Os valores contínuos das variáveis QtdElementos, QtdTravas, TempoGasto e QtdMensagens foram obtidos a partir dos dados armazenados no log da ferramenta.

A transformação dos valores contínuos destas variáveis em valores discretos se baseia na observação e análise dos valores contínuos e no contexto no qual os pares executaram cada tarefa. Por exemplo, o valor discreto Alta para a variável QtdMensagens, atribuída a uma tarefa executada por um par, leva em consideração o valor contínuo da variável, o canal de comunicação utilizado e a comparação com os valores contínuos dos demais pares para esta mesma tarefa e variável. Para os valores das variáveis EsforçoPercebido e DificuldadeApontada nenhuma transformação foi necessária, pois eles foram coletados diretamente dos questionários de esforço requerido que continham perguntas cujas respostas apresentavam escalas de valores correspondentes aos da Tabela 1 para estas variáveis.

Nome da variável Descrição da variável Valores discretos

QtdsElementos Quantidade de elementos criados Alta(3), Média(2), Baixa(1)

QtdTravasQuantidade de travas concedidas nos elementos do modelo

Alta(3), Média(2), Baixa (1)

TempoGasto Tempo de duração total da tarefa Longo(3), Médio (2), Curto(1)

EsforçoPercebidoGrau de esforço percebido pelo par durante a realização tarefa

Muito esforço(5), Algum esforço(4), Esforço razoável(3), Pouco esforço (2), Nenhum esforço(1)

DificuldadeApontadaGrau de dificuldade apontado pelo par durante a realização da tarefa

Muito difícil(5), Difícil(4), Nem difícil nem fácil(3), Fácil(2), Muito fácil(1)

QtdMensagensQuantidade de mensagens relevantes enviadas durante a comunicação

Alta(3), Média(2), Baixa(1)

4 ALTERNATIVA DE AVALIAÇÃO DA EVOLUÇÃO DA EFICÁCIA

A análise da evolução da eficácia de aprendizado dos alunos, para a resolução dos problemas, é realizada considerando o conjunto de problemas, assim é possível ter um mapeamento superficial do desempenho dos alunos. Com os dados obtidos das variáveis, o professor pode medir a eficácia de aprendizado dos alunos baseado no aspecto que melhor lhe convir. Neste artigo sugerimos a utilização de um índice de aproveitamento que leva em consideração todas as variáveis observadas durante o experimento, com o objetivo de auxiliar na avaliação do desempenho do aprendizado dos grupos na resolução dos problemas de forma colaborativa. O cálculo do índice de aproveitamento dos pares na execução das tarefas foi baseado nas variáveis descritas na seção anterior.


59

O valor entre parênteses apresentado após o valor discreto das variáveis na Tabela 1 é somado para cada tarefa de cada par. Deste modo, o índice considera que o par teve um bom aproveitamento se todas as variáveis apresentarem valores altos, tais como uma grande quantidade de elementos criados ou um maior tempo gasto durante a tarefa. O índice de aproveitamento é calculado em percentual com base no aproveitamento máximo possível obtido através da soma dos valores de todas as variáveis observadas. Um gráfico de colunas com o índice de aproveitamento calculado para cada par e tarefa é apresentado na Figura 1. Este gráfico apresenta, em colunas, o aproveitamento dos pares em cada uma das tarefas, considerando o índice de aproveitamento, em porcentagem. Analisando os dados do gráfico pode-se inferir que os alunos do par 5 foram os únicos alunos cujo aproveitamento foi constante nas tarefas 1 e 2, fato que pode ser explicado pelos valores discretos iguais para as variáveis QtdTravas e TempoGasto nas duas primeiras tarefas realizadas por estes pares. Já os pares 1, 4 e 6 mostraram um maior aproveitamento na tarefa 2, pois eles possuíram o valor discreto Alta para a variável QtdMensagens, valor este que provavelmente influenciou de forma direta os valores das outras variáveis. Os pares 2 e 3 possuem uma queda de aproveitamento em comum nas tarefas 2 e 3, que pode ser explicado pelo pouco tempo gasto na execução destas tarefas em conjunto e também devido ao pouco esforço gasto na execução destas tarefas.

61 61

43 43

74

61

39 30

6978

87

5652 52

74

100

90

8070

6050

40

30

20

10

0

62 62 62

Par 1 Par 2 Par 3 Par 4 Par 5 Par 6

Pares

Apr

ovei

tam

ento

(%)

Tarefa 1

Tarefa 2

Tarefa 3

O índice de aproveitamento sugerido é uma proposta que auxilia a avaliação do aprendizado dos alunos e deve ser utilizado em conjunto com outros métodos de avaliação qualitativa, como, por exemplo, a nota que o professor atribui às soluções dos problemas apresentados. Este índice é relevante para pesquisados e educadores que estão envolvidos na análise e avaliação das atividades de aprendizado e na modelagem e criação de novas ferramentas e métodos para o estudo da eficácia de aprendizado em atividades colaborativas. Ele tem como objetivo fornecer uma ideia superficial da eficácia e produtividade do aprendizado dos grupos de alunos e ajudar o professor a detectar mais facilmente o aproveitamento no aprendizado.

60


5 CONSIDERAÇÕES FINAIS

Este trabalho apresentou dados coletados a partir do uso de uma ferramenta de modelagem colaborativa e propôs uma alternativa de avaliação do aprendizado de grupos de alunos que utilizaram uma ferramenta colaborativa para auxiliar o aprendizado da UML em um experimento controlado.

A utilização de ferramentas de groupware na instrução abre novas possibilidades de aprendizado. Entretanto, a medição e a avaliação do desempenho do aprendizado auxiliado por ferramentas colaborativas ainda carecem de estudos mais aprofundados. Por meio da análise das interações dos alunos entre si e com a ferramenta foi possível identificar os problemas que apresentaram maior ou menor grau de dificuldade aos grupos, e também identificar os aspectos que podem influenciar no aprendizado colaborativo. Com a possibilidade de coleta dos dados e do índice de desempenho apresentados neste artigo, espera-se auxiliar o professor na avaliação do desempenho do aprendizado dos grupos de alunos, além de fornecer recursos para que o professor possa acompanhar e conhecer as dificuldades no aprendizado dos alunos quando estes utilizam uma ferramenta colaborativa. Desta maneira, a atividade de avaliação geral do professor pode ser amenizada, principalmente no aspecto do acompanhamento do aprendizado do aluno. O ArgoUML adaptado para permitir a edição colaborativa síncrona está disponível para download no endereço: <http://www.comp.ita.br/~pichilia/argo.htm>.

Agradecimentos. Os autores gostariam de agradecer aos revisores anônimos que contribuíram para a melhoria deste trabalho e a todos os envolvidos na elaboração do experimento.

FONTE: Disponível em: <http://www.comp.ita.br/pichilia/argo.htm>. Acesso em: 10 out. 2015.

61

RESUMO DO TÓPICO 3

Neste tópico você viu que:

• Um diagrama de atividade mostra um processo de negócios ou um software como um fluxo de trabalho por meio de uma série de ações. Computadores, componentes de software ou as pessoas podem executar essas ações.

• Você pode usar um diagrama de atividades para descrever processos de diversos tipos, como os exemplos a seguir:

o Um processo de negócios ou um fluxo de trabalho entre usuários e seu sistema. Para obter mais informações, consulte Requisitos de usuário do modelo.

o As etapas executadas em um caso de uso. Para obter mais informações, consulte Diagramas de caso de uso UML: diretrizes.

o Um protocolo de software, ou seja, as sequências permitidas de interações entre os componentes.

o Um algoritmo de software. • O diagrama de máquina de estados mostra os estados que podem ser assumidos

por um objeto em seu ciclo de vida. Geralmente o utilizamos para entender como tais mudanças acontecem, de modo a podermos definir as trocas de mensagens e os métodos que as controlam.

62

1 Analise o Diagrama de Casos de Uso abaixo, referente a um módulo de matrícula, e construa um Diagrama de Atividades para demonstrar modelagem dos processos do negócio.

AUTOATIVIDADE

Aluno

ConsultarInformaçõesde Turmas

Manter Aluno RealizarMatrícula

ConsultarInformaçõesde Cursos

<<extend>>

<<extend>>

<<include>>

2 Construa um Diagrama de Atividades para o seguinte processo de negócio:

- A autorização do pagamento tem início após um pedido ter sido realizado pelo cliente.

- Ao mesmo tempo, a disponibilidade para cada um dos itens do pedido é verificada pelo depósito.

- Se a quantidade requisitada de um determinado item existe em estoque, tal quantidade é associada ao pedido, caso contrário, a quantidade do item será alterada (se houver em quantidade menor), se a quantidade em estoque for igual a zero, o item será excluído.

- O pedido é enviado pelo depósito ao cliente quando todos os itens estiverem associados e o pagamento estiver autorizado.

- O pedido será cancelado se a ordem de pagamento não tiver sido autorizada.

3 Desenhe o diagrama de estados de uma tostadeira. Defina os diferentes estados do pão na tostadeira, sem esquecer de especificar os necessários eventos, ações e condições com guarda.

4 Uma das formas de modelar o aspecto dinâmico de um sistema com a UML 2.0 é através da utilização do diagrama de máquina de estado (state machine diagram). Nesse contexto, considere os dois diagramas de máquinas de estados representados a seguir, de acordo com a notação da UML. Considere que os eventos e as atividades homônimas em ambos os diagramas têm o mesmo significado.

63

entry/atividade00evento01/atividade01evento02/atividade02

A

B

evento03

entry/atividade00evento01/atividade01

A

B

evento03

evento02/atividade02

Os dois diagramas de máquinas de estados apresentados são equivalentes entre si. PORQUE

Modelar o evento02 com uma transição recursiva (conforme o diagrama da direita) é equivalente a modelar o evento02 com uma atividade interna (conforme o diagrama da esquerda).

Analisando-se as afirmações acima, conclui-se que:

a) As duas afirmações são verdadeiras, e a segunda justifica a primeira.b) As duas afirmações são verdadeiras, e a segunda não justifica a primeira.c) A primeira afirmação é verdadeira, e a segunda é falsa.e) As duas afirmações são falsas.

65

UNIDADE 2

DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)


PLANO DE ESTUDOS

Ao final desta unidade você será capaz de:

• conhecer as principais características dos diagramas compor-tamentais;

• elaborar diagramas comportamentais de interação;

• conhecer as principais características dos diagramas estruturais;

• elaborar diagramas estruturais.

Esta unidade de ensino contém três tópicos e no final de cada um deles você encontrará atividades que contribuirão para a apropriação dos conteúdos.

TÓPICO 1 – DIAGRAMAS DE INTERAÇÃO TÓPICO 2 – DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES TÓPICO 3 – DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPO-

NENTES

67

TÓPICO 1

DIAGRAMAS DE INTERAÇÃO

UNIDADE 2

1 INTRODUÇÃO

Diagramas de Interação representam como o sistema age internamente para que um ator atinja seu objetivo na realização de um caso de uso, com o objetivo de obter informações adicionais para completar e aprimorar outros modelos (principalmente o modelo de classes), além de fornecer aos programadores uma visão detalhada dos objetos e mensagens envolvidos na realização dos casos de uso.

A mensagem é o componente principal da interação entre objetos. Um sistema orientado a objetos é uma rede de objetos que trocam mensagens. Objetos só podem interagir através de mensagens. Por exemplo: um objeto envia uma mensagem para outro objeto quando o primeiro deseja que o segundo realize alguma tarefa. Neste sentido, os Diagramas de Interação mostram como os objetos interagem uns com os outros, sendo usados tanto na análise quanto no desenvolvimento do projeto de forma geral.

Estes diagramas modelam aspectos dinâmicos do sistema, ou seja, as situações que sofrem mudanças ao longo do tempo.

Os Diagramas de Interação são: Diagrama de Sequência, Diagrama de Comunicação, Diagrama de Tempo e Diagrama de Visão Geral.

2 DIAGRAMA DE SEQUÊNCIA

Detalham a sequência de um processo, representando os atores e objetos envolvidos num cenário e a sequência de troca de mensagens ao longo do tempo para realizar o cenário. É construído a partir do diagrama de casos de uso. Ordena de forma temporal as mensagens trocadas entre os objetos.

A notação para uma mensagem em um Diagrama de Sequência é uma flecha (geralmente desenhada na horizontal) ligando uma linha de vida à outra. O objeto do qual parte a seta é aquele que está enviando a mensagem (objeto remetente). O objeto para o qual a seta aponta é aquele que está recebendo a mensagem (objeto receptor). O formato da ponta da seta indica o tipo de mensagem sendo enviada (síncrona ou assíncrona). O rótulo da mensagem é posicionado acima dessa seta.

UNIDADE 2 | DIAGRAMAS COMPORTAMENTAIS (INTERAÇÃO)

68

Um Diagrama de Sequência permite identificar os métodos e atributos de cada classe, assim como as responsabilidades de cada classe na realização de um caso de uso. Os elementos básicos de um Diagrama se Sequência são (TACLA, 2010, p. 36):

• Atores: São entidades externas que interagem com o sistema e que solicitam serviços. Normalmente, o ator primário é o responsável por enviar a mensagem inicial que inicia a interação entre os objetos.• Objetos: Representam as instâncias das classes representadas no processo.• Linha do tempo (uma para cada objeto e ator): As linhas de vida compõem a dimensão vertical. Uma linha de vida é composta de duas partes, a cabeça e a cauda. A cabeça é representada por um retângulo com dois compartimentos, no compartimento superior a identificação do objeto é exibida e no compartimento inferior (cuja utilização é opcional) aparecem valores para os atributos definidos na classe do objeto. A cauda corresponde a uma linha vertical tracejada.• Comunicação: entre ator e objeto ou entre objetos.• Interpretação das mensagens: por exemplo, evento do sistema operacional ou de uma interface, envio de mensagem ou chamada de método.

FIGURA 33 – REPRESENTAÇÃO DE DIAGRAMA DE SEQUÊNCIA

usuário

objeto

sincrona

resposta

assincrona

ativação|

Linha davida

:A :B

FONTE: Piva (2010)

2.1 TIPOS DE MENSAGEM

Há vários tipos de mensagem que podem ser utilizados num Diagrama de Sequência, sendo os mais comuns os seguintes:

TÓPICO 1 | DIAGRAMAS DE INTERAÇÃO

69

• Simples: quando o tipo de mensagem é irrelevante ou ainda não foi definido.• Síncrona: quando enviada, o emissor fica bloqueado aguardando a resposta.• Assíncrona: o emissor não bloqueia até que o receptor envie resposta para

continuar seu processamento.• Retorno ou resposta: resposta à mensagem síncrona; pode ser omitida.

Uma mensagem é definida sintaticamente por:

• Expressão-sequência recorrência: v := mensagem• Expressão-sequência: é um número sequencial de envio das mensagens.

Por exemplo, 1: msg1 2: msg2 representando que a mensagem msg1 precede a msg2.

• Recorrência: indica um envio condicional ou uma repetição. Zero ou mais mensagens são enviadas dependendo da condição envolvida. As opções são:

*[cláusula-iteração] ou[guarda]

Não há sintaxe rígida definida pela UML, a cláusula de interação e a condição de guarda podem ser especificadas em pseudocódigo ou na linguagem-alvo.


Utiliza-se um Diagrama de Sequência quando há a necessidade de representar o comportamento de vários objetos dentro de um contexto específico, a partir de mensagens que são trocadas entre eles. Os atores são os mesmos do diagrama de casos de uso. Um Diagrama de Sequência não representa atributos.

Passos para a criação de um Diagrama de Sequência:

• Escolher um caso de uso • Identificar os objetos que fazem parte da interação • Identificar o objeto que começa a interação • Identificar as mensagens trocadas entre os objetos • Identificar a sequência destas mensagens

Notação do Diagrama de Sequência


70

FIGURA 34 – NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA

Objeto

Ator

Mensagens

Tempo

FONTE: Disponível em: <http://www.dmo.fee.unicamp.br/henrique/cursoc++/diagrama.pdf>. Acesso em: 10 out. 2015.

Exemplo de Diagrama de Sequência

FIGURA 35 – EXEMPLO DE DIAGRAMA DE SEQUÊNCIA

Cliente Atendente Gerente

Comunicar extravio de fita

Solicitar registro de aluguel

Retornar registro de aluguel

Retornar registro da fita

Buscar aluguel

Buscar fita

Solicitar registro da fita

Solicitar conversa com gerente.

Negociar Multa

Falar com Gerente

Pagar Multa

Sistema daVideoLocadora

FONTE: Disponível em: <http://www.dmo.fee.unicamp.br/henrique/cursoc++/diagrama.pdf>. Acesso em: 10 out. 2015.

2.2 DIAGRAMA DE COMUNICAÇÃO

Antes da versão 2.0 era chamado de Diagrama de Colaboração. Contempla as mesmas informações que o Diagrama de Sequência, mas não considera a dimensão temporal.

Considerando a sua estrutura, é semelhante a um Diagrama de Objetos, sendo que a principal diferença entre os dois é que são adicionados setas e rótulos


71

de mensagens nas ligações entre esses objetos. E as ligações (linhas que ligam objetos) remetem aos relacionamentos existentes entre os mesmos.

2.2.1 Principais componentes: objetos, mensagens e vínculo

Para Tacla (2010, p. 34) “o Diagrama de Comunicação mostra a relação entre os objetos, analisando a troca de mensagens entre eles. Mas não se preocupa necessariamente com a ordem em que elas ocorrem, e sim com quais objetos as mensagens são trocadas e quais são as mensagens”.

Diferente de um Diagrama de Sequência, um Diagrama de Comunicação mostra os relacionamentos entre os objetos. Os Diagramas de Sequência e os Diagramas de Comunicação expressam informações semelhantes, mas as mostram de maneiras diferentes. Os Diagramas de Comunicação mostram os relacionamentos entre os objetos e proporcionam uma melhor compreensão de todos os efeitos causados em determinado objeto e para design de procedimentos.

Observe a Figura 36. Verifique que a composição é basicamente a mesma de um Diagrama de Sequência, porém, em ordem diferente, com foco para as mensagens trocadas entre os objetos, não em quando estas mensagens foram trocadas.

Pode-se então escolher em usar o Diagrama de Sequência ou o Diagrama de Comunicação, podendo obviamente optar por criar os dois quando se tem uma situação atípica para analisar.


72

FIGURA 36 – COMPONENTES DO DIAGRAMA DE COMUNICAÇÃO

:ItemCompra

:Compra

:Funcionario

Produto:Cliente :FRegistraProduto

1: verifi caFuncionario(cpf,senha): boolean3: valorUnitario=verifi caProduto(produto,quantidade): double

4: ItemCompra(produto,quantidade,precoUnitarioVenda,funcionario: boolean

5: atualizaTotalCompra(valorTotalItem: boolean

2: verifi caCartao(nroCartao): boolean

FONTE: Piva (2010)

• Também chamado de Diagrama de Colaboração. • Defi ne a estrutura de como os objetos estão vinculados. • Semelhante ao Diagrama de Classes. • Indica quais mensagens são trocadas entre objetos. • Semelhante ao Diagrama de Sequência S.• Diagrama de Sequência se concentra na ordem temporal em que as mensagens

são trocadas.• Diagrama de Comunicação se preocupa com a organização estrutural dos

objetos.

2.2.2 Notação: semelhante ao Diagrama de Sequência

Um dos principais objetivos do Diagrama de Comunicação é identifi car os vínculos que são ligações existentes entre os objetos envolvidos no processo.

Um vínculo é representado por uma linha unindo dois objetos.Deve existir relacionamento equivalente no Diagrama de Classes.


73

FIGURA 37 – NOTAÇÃO

curso1: Curso turma1:Turma

FONTE: O autor

As notações são as mesmas definidas no Diagrama de Sequência e geralmente representam chamadas de métodos.

No Diagrama de Comunicação não existe a preocupação com a ordem, somente com quem dispara a mensagem, não existindo mensagens de retorno.

FIGURA 38 – REPRESENTAÇÃO DE MENSAGENS

curso1: Curso turma1:Turma

1: VisTurma( )

FONTE: O autor

2.2.3 Atores

São os mesmos do Diagrama de Sequência e Casos de Uso. Atores enviam e recebem mensagens através de vínculos, assim como ocorre com os objetos no Diagrama de Comunicação.

2.2.4 Condições

São condições que devem ser atendidas para que uma mensagem possa ser enviada. Notação: a condição vem entre colchetes antes da mensagem.

FIGURA 39 – REPRESENTAÇÃO DE CONDIÇÕES

Gerente

minha_conta: Conta

[se saldo = 0] encerrarConta( )

FONTE: O autor


74

2.2.5 Autochamadas

Objetos podem disparar mensagens para eles mesmos, como ocorre no Diagrama de Sequência. Esta situação indica que o objeto tem que fazer determinada tarefa para finalizar o serviço solicitado.

FIGURA 40 – REPRESENTAÇÃO DE AUTOCHAMADAS

fisica1:Fisica

1: valCPF0FONTE: O autor

2.2.6 Exemplo de Diagrama de Comunicação

FIGURA 41 – DIAGRAMA DE COMUNICAÇÃO

:Banco

hist1: Históricoconta1: Conta Comum

fisica1:Fisica

1: conCPF0

2: [Se necessário] Gravar ( )

4: Gravar ( )

3: Abertura ( )

FONTE: O autor

Passos para criar um Diagrama de Comunicação

• Verificar a consistência dos diagramas de interação em relação aos Casos de Uso e ao modelo de classes.

• Cada cenário relevante para cada caso de uso deve ser considerado na modelagem de interações.

• Durante a construção do Diagrama de Interação pode-se identificar novas classes.

• Atributos, associações e operações também surgem como subproduto da construção dos Diagramas de Interação.


75

2.3 DIAGRAMA DE TEMPO

O Diagrama de Temporização foi incluído a partir da UML 2.0 e apresenta o comportamento dos objetos e sua interação em uma escala de tempo, sempre com foco para as situações que mudam num determinado intervalo, além de descrever a interação e a evolução de estados, e de monitorar as restrições temporais do sistema (MELO, 2011).

Colaborando, Guedes (2011, p. 76) complementa: “O Diagrama de Temporização ou de tempo apresenta a mudança no estado ou condição de uma instância de uma classe ou seu papel durante um período. Utilizado para mostrar a mudança no estado de um objeto no tempo em resposta a eventos externos”.

É um diagrama de interação, pois mostra os tempos reais em diferentes objetos e papéis, em vez de sequências de mensagens relativas. São geralmente utilizados em projetos de sistemas de tempo real, onde impera o tempo gasto na troca de mensagens e de estado na execução de todas as tarefas. Por este motivo, não são utilizados em todos os tipos de projetos, somente nos casos em que o tempo seja um fator determinante (TACLA, 2010).

Descreve a mudança no estado ou na condição de uma instância de uma classe ou seu papel durante um tempo. É tipicamente utilizado para demonstrar a mudança no estado de um objeto no tempo em resposta a eventos externos.

Os principais componentes do diagrama de tempo são: classes, linha de tempo, mensagens. A figura a seguir mostra um exemplo de diagrama de tempo.

td Sistema de Controle de Submissões - Estados do Congresso

Aceitando submissões

{03/01..31/03} {01/04..31/05} {01/06..15/06} {11/07..15/07}

Avaliando submissões

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100

Comunicando autores

Realizando congresso

:Con

gres

so

FIGURA 42 – DIAGRAMA DE TEMPO

FONTE: Disponível em: <https://www.novatec.com.br/livros/uml2-2ed/capitulo9788575223857.pdf>. Acesso em: 15 out. 2015.


76

2.4 DIAGRAMA DE VISÃO GERAL

Através do Diagrama de Visão Geral é possível aglomerar vários tipos distintos de diagramas. Podemos entendê-lo como uma variação dos diagramas de atividade e sequência, uma vez que sua notação é a mesma destes dois diagramas.

São utilizados em situações complexas, para simplificar determinadas situações. São eficazes em reuniões quando existe a necessidade de demonstrar cenários de alta complexidade. Uma particularidade é que, conforme mencionado acima, não possui uma notação específica.

Este diagrama permite capturar de uma perspectiva estática os fluxos de interação entre os componentes do sistema, de forma geral, do funcionamento global do sistema, de forma similar ao modelo expresso pelo Diagrama de Atividades, que mostra o fluxo de um subsistema, ou de uma dada funcionalidade em questão (TACLA, 2010, p. 45).

Ainda de acordo com o autor, o objetivo precípuo deste diagrama consiste em analisar as sequências necessárias para executar determinada funcionalidade do sistema que está sendo elaborado. Como exemplo de funcionalidade podem ser citados vários casos de uso.

Os principais componentes do diagrama de visão geral são: diagramas de sequência, decisões, fluxos.

77

RESUMO DO TÓPICO 1


• Os Diagramas de Interação constituem um passo importante nesta divisão, pois detalham os objetos das classes de análise e, por consequência, quais operações cada um deve realizar. Se um caso de uso possui vários fluxos, pode ser útil criar um diagrama de interação para cada cenário. Os diagramas de interação mais utilizados são o de Sequência e o de Comunicação (ex-colaboração).

• Diagramas de Interação são usados tanto na análise quanto no projeto. Na análise, as comunicações entre objetos são mais abstratas, não importando muito os argumentos e valores retornados. No projeto, o detalhamento é maior.

• Os diagramas de Interação são: Diagrama de Sequência, Diagrama de Comunicação, Diagrama de Tempo e Diagrama de Visão Geral.

• Um Diagrama de Sequência representa os atores e objetos envolvidos num cenário e a sequência de troca de mensagens ao longo do tempo para realizar o cenário.

• Um Diagrama de Sequência permite identificar os métodos e atributos de cada classe, assim como as responsabilidades de cada classe na realização de um caso de uso. Os elementos básicos de um Diagrama de Sequência são:

oAtoresoObjetosoLinha do tempo (uma para cada objeto e ator)oComunicação entre ator e objeto ou entre objetosoInterpretação das mensagens: por exemplo, evento do sistema operacional ou

de uma interface, envio de mensagem ou chamada de método.

• Diagrama de Comunicação (antes da versão 2.0 era chamado Colaboração) é outra forma de representar um cenário: contém as mesmas informações que o Diagrama de Sequência, mas não considera a dimensão temporal. Alguns autores recomendam utilizá-lo para analisar a colaboração das classes de realização de um caso de uso, pois facilita a identificação das classes que colaboram de forma mais próxima e, por consequência, a identificação de pacotes de análise.

oPrincipais componentes: objetos, mensagens.

• O Diagrama de Comunicação mostra a relação entre os objetos, analisando a troca de mensagens entre eles. Mas não se preocupa necessariamente com a ordem em que elas ocorrem, e sim com quais objetos as mensagens são trocadas e quais são as mensagens.

78

• Em muitos projetos, usa-se ou o Diagrama de Sequência ou o Diagrama de Comunicação, mas também pode-se criar ambos para análise de alguma situação particular.

• É um Diagrama de Interação, que mostra os tempos reais em diferentes objetos e papéis, em vez de sequências de mensagens relativas (BOOCH; RUMBAUGH; JACOBSON, 2005).

• O Diagrama de Temporização, como o nome diz, tem seu foco principal no estudo do tempo gasto nas trocas de mensagens entre os componentes do sistema.

• Esse é um diagrama de uso específico, que não se utiliza em todos os projetos. o Principais componentes: classes, linha de tempo, mensagens.

• O Diagrama de Visão Geral Congrega uma determinada visão que pode englobar vários diagramas.

• Geralmente o Diagrama de Visão Geral de interação é uma variação do Diagrama de Atividades mais o Diagrama de Sequência, proposto na versão atual de UML. Seus elementos sintáticos são os mesmos dos Diagramas de Atividades e Sequência.

• As interações que fazem parte do Diagrama de Visão Geral de interação podem ser referências a diagramas de interação existentes na especificação tratada.

• É necessário, em casos em que as sequências das interações se mostrarem tão complexas, que requisitem um resumo que possibilite uma visão geral daquela situação.

• É muito eficaz em reuniões e demonstrações de situações complexas, devemos utilizá-lo de forma intensiva, pois não existe outro diagrama que nos dê uma visão tão completa dos passos que uma situação, classe ou objeto possa passar.

• Não possui notações próprias.

• Em geral usa as mesmas notações dos diagramas dos quais está englobando.

• Geralmente usa a mesma notação do Diagrama de Atividades.

o Principais componentes: diagramas de sequência, decisões, fluxos.

79

AUTOATIVIDADE

1 Construa um Diagrama de Sequência para abrir uma conta, conforme a descrição abaixo:

O cliente que deseja abrir uma conta no banco encaminha um pedido de abertura de conta, com a documentação necessária. O funcionário do banco, então, irá consultar o cadastro do cliente por meio do seu CPF, para determinar se o solicitante já se encontra cadastrado. Se o cliente já estiver cadastrado, a consulta retornará as informações do cliente, caso contrário retornará um valor significando que o cliente ainda não possui cadastro na instituição. Em seguida, o cadastro do cliente poderá ser atualizado, caso necessário, podendo gerar uma nova instância da classe Cliente, se o solicitante ainda não estiver registrado, ou simplesmente atualizar os dados do mesmo, se houver necessidade de alguma atualização. Antes de finalizar a atualização do cliente, algumas inconsistências devem ser levadas a efeito, uma delas é o disparo do método para validação do CPF pelo próprio objeto da classe Cliente. Após o término da atualização, o objeto da classe cliente retornará algum sinal para o funcionário do banco, para indicar que o cliente foi atualizado com sucesso ou se ocorreu algum erro. O banco então irá informar ao cliente se o seu pedido foi ou não aprovado. Em caso de aprovação, o cliente irá fornecer o valor inicial necessário para a abertura da conta e escolherá a senha. O funcionário irá disparar o método de abertura na classe ContaComum, ou seja, criará um novo objeto ContaComum. Após ter sido criado pela chamada do método abertura, o objeto de ContaComum irá disparar o método gravar para gerar uma nova instância da classe Historico, registrando o movimento gerado pela abertura da conta, pois, para abrir uma conta, a instituição exige que o cliente deposite algum valor na mesma. O método gravar retornará um sinal indicando que o movimento foi registrado com sucesso e o método abertura disparado na classe ContaComum, por sua vez, retornará o número da conta gerado, indicando que a conta foi criada com sucesso e finalizando o processo de abertura de conta.

FONTE: Disponível em: <http://professoralucelia.com.br/projSistemas/ExerciciosDiagramaDeSequencia03.pdf>. Acesso em: nov. 2015.

2 Elabore um Diagrama de Comunicação para que um cliente possa abrir uma conta.

Utilize as classes PessoaFisica, ContaComum e Histórico, conforme modelo abaixo.

Como atores, considere Cliente e Banco.

80

PessoaFisica

+ ConsultaCP F( )+ ValidaCPF ( )+ Gravar ( )

: Int: System .Boolean: System .Boolean

Historico

+ Gravar ( ): System . Booelan

ContaComum

+ Abertura ( ) : Int

3 São diagramas de interação da UML que mostram um conjunto de objetos e as mensagens que poderão ser trocadas entre eles, enfatizando a ordem temporal de mensagens:

a) Diagrama de Atividades.b) Diagrama de Objetos.c) Diagrama de Comunicação.d) Diagrama de Sequências.

4 Analise as seguintes afirmativas sobre os Diagramas de Interação da UML.

I - Um Diagrama de Interação mostra a interação entre um conjunto de objetos e seus relacionamentos, incluindo as mensagens que poderãos ser trocada entre eles.

II - Diagramas de Sequência e Diagramas de Colaboração são Diagramas de Interação e modelam aspectos dinâmicos de sistemas.

III - Diagramas de Colaboração dão ênfase à ordenação temporal das mensagens trocadas entre os objetos.

Marque a alternativa CORRETA:

a) ( ) Apenas as afirmativas I e II são verdadeiras.b) ( ) Apenas as afirmativas I e III são verdadeiras.c) ( ) Apenas as afirmativas II e III são verdadeiras.d) ( ) Todas as afirmativas são verdadeiras.

81

TÓPICO 2

DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES

UNIDADE 2

1 INTRODUÇÃO

Modelam as situações estáticas do sistema, ou seja, seu esqueleto e estruturas estáveis, que não sofrem mudanças (OMG, 2006).

Para Andrade (2007, p. 68), “a função dos diagramas estruturais é mostrar as características do sistema que não mudam ao longo do tempo. Os aspectos estáticos de um sistema de software envolvem a existência e a colocação de itens como classes, interfaces, colaborações, componentes”. A figura a seguir, ilustra os diagramas estruturais da UML.

FIGURA 42 - DIAGRAMAS ESTRUTURAIS

DiagramasEstruturais

Diagramade Objetos

Diagrama de EstruturaComposta

Diagrama deComponentes

Diagrama deImplantação

Diagramade Pacotes

Diagramade Classes

Diagrama deImplementação

FONTE: Piva (2010)

2 DIAGRAMA DE CLASSES

É apontado como sendo o diagrama mais utilizado, pois mostra o conjunto de classes, interfaces, colaborações e relacionamentos. Sua utilização é ampla, tendo início desde o momento da análise até o detalhamento da especificação (GUEDES, 2011). É considerado também o diagrama que possui o maior detalhamento quando pensamos em notações.

É este diagrama que se aproxima mais da realidade de um código de programa, pois mostra conjunto de classes com seus atributos e métodos e os relacionamentos entre classes, amplamente utilizado no desenvolvimento de aplicações orientadas a objetos (LARMAN, 2007).


82

Apresenta as relações:

• associação (mais comum);• agregação (um tipo de associação);• generalização/especialização.

FIGURA 43 – CLASSE CLIENTE

Clientes- codPessoa- num Cliente+ setCadastrar ( )+ getConsultar ( )

FONTE: O autor

A importância deste diagrama consiste no fato de que cada classe do diagrama representa uma tabela do banco de dados. Importante frisar que para identificar uma classe é necessário que antes se identifiquem os objetos que contenham características familiares ou semelhantes.

Quando se analisa uma situação real (cenário), é normal que se identifiquem vários objetos. Porém, nem todos farão parte do Diagrama de Classes. Para identificar os objetos essenciais deve-se colocar em prática o conceito de abstração, cuja finalidade é manter o foco somente nos aspectos relevantes da situação.

Como exemplo para o desenvolvimento do Diagrama de Classe, usaremos o cenário proposto por Tacla (2010, p. 65). Neste exemplo será possível identificar todas as classes para fazermos as ligações e determinarmos a cardinalidade.

2.1 CENÁRIO

Você trabalha para uma empresa de desenvolvimento como analista de sistemas. O responsável pelo setor onde você trabalha, em uma reunião, distribuiu tarefas para cada membro da equipe. Sua tarefa foi desenvolver um diagrama de classe para que seja iniciado o desenvolvimento de um novo software.

A empresa que nos contratou deseja adquirir o certificado ISO 9001 em qualidade, entretanto, uma das normas repassadas foi que deve ser obrigatório controlar os pedidos de suporte/serviço que são feitos pelos clientes.

O ramo da empresa é Service Desk[1] e o fluxo do processo segue abaixo:

TÓPICO 2 | DIAGRAMAS ESTRUTURAIS: DE CLASSES E DE PACOTES

83

Cliente entra em contato com a central através do telefone

Um atendente tem um prazo curto para registrar esta solicitação, informando os dados do cliente, o que foi solicitado, o nível de urgência, o grupo de atendimento, o técnico, um ou mais equipamentos envolvidos na manutenção. Anotar toda a interação realizada no equipamento, como, por exemplo: Se ele conectar remotamente ao equipamento, deve informar em um histórico, e suponhamos que três segundos depois ele reinicie o equipamento, deverá informar no histórico também. Resumindo: Toda interação deve ser anotada no registro com data e hora.

Caso ele consiga resolver o que foi solicitado, o técnico do Service Desk irá salvar o registro com a situação de “Resolvido” encerrando o caso, contudo, deverá, em um local específico do registro, definir como ele resolveu o caso, informando que se tratava de um Incidente[2], Problema[3] ou Solicitação[4]. O registro deve ser categorizado, escolhendo dentre três classificações: Categoria >>SubCategoria >> Item da categoria, onde a categoria é uma lista de tipo de serviço, como, por exemplo: Se foi Hardware ou Software.

FONTE: Disponível em: <http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-elaboracao-de-um-diagrama-de-classes.aspx>. Acesso em: nov. 2015.

A SubCategoria está relacionada com a categoria, pois dependendo do que foi escolhido na primeira lista, será mostrada na segunda que será uma SubCategoria, como, por exemplo: No caso da escolha de Hardware, seria informado na subcategoria algum tipo de peça do equipamento que o técnico interagiu, tipo DVD/R, no caso de Categoria ser Software a subcategoria deveria ser qual software, tipo: Word, Excel e etc... E no item da categoria deveria ser escolhido o que foi realizado pelo técnico, no caso de Hardware >> DVD/R, poderia ser SUBSTITUÍDO, LIMPADO... etc. No caso de Software >> Word >> INSTALADO, DESINSTALADO etc...

Caso o técnico do Service Desk não consiga resolver no seu prazo que será o mais curto, deverá enviar o registro para outro grupo de atendimento, onde existirão outros técnicos que poderão ir até o equipamento fisicamente para resolver o problema com um prazo mais extenso. Um grupo é composto por vários técnicos, no registro deve constar o grupo que atendeu e o técnico, pois cada registro conta como receita em reais para o grupo sendo apurado ao efetuar fechamento mensal. O pagamento para os grupos de atendimento é feito por quantidade de registros atendidos no prazo estipulado.


84

Se o mesmo grupo de atendimento físico tenta entrar em contato com o cliente, mas não obtiver sucesso, o técnico poderá deixar o registro agendado; para realizar esta tarefa devem ser informadas no registro a data e a hora em que será retornado o atendimento do chamado e definir a situação do registro para “Pendente pelo cliente”, definir também a data e hora para o próximo contato. Esta situação de pendência significa que o técnico não está atendendo por culpa do cliente e o tempo em que o registro fica nesta situação será debitado ao final da apuração, a fim de beneficiar o grupo que o atende, pois cada grupo tem um tempo para atender os registros, e se ultrapassar este prazo, recebe multa em cima do valor do chamado.

Ao final, caso o pedido tenha sido designado para outro grupo, ou esteja em andamento, pendente, cancelado ou resolvido, deve-se informar em um campo específico o que foi feito neste registro, resumidamente. Se a situação do registro estiver definida como “Resolvido”, uma pesquisa de satisfação deverá ser enviada para o solicitante.

FONTE: Disponível em: <http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-elaboracao-de-um-diagrama-de-classes.aspx>. Acesso em: nov. 2015.

2.2 IDENTIFICAR OS OBJETOS TANGÍVEISPara identificar somente os objetos que interessam na situação detalhada

acima, Tacla (2010) sugere que adotemos como regra o seguinte questionamento: “O objeto é algo tangível, que podemos percebê-lo à nossa frente, sendo possível encontrá-lo no mundo real ou virtual. Exemplos de objetos que podemos perceber ao ir a uma lanchonete: Mesa, Cadeira, Atendente, Lanche, Bebida e etc.”.

Analise frase a frase do cenário proposto, obedecendo à regra descrita acima.

Logo, você identificará os seguintes objetos:

ClienteTelefoneAtendenteSolicitaçãoGrupoTécnicoEquipamentoHistóricoCategoriaSubCategoriaItem da categoriaPedidoPesquisa de satisfaçãoSituaçõesTipo de serviçosPrazos


85

Histórico não é algo tangível, porém, é algo que existe. Neste caso, podemos entender como o histórico de ocorrências envolvendo o cliente.

2.3 AGRUPAR OS OBJETOS POR SEMELHANÇA

Todos os objetos encontrados devem ser agrupados quando houver semelhança. Exemplo:

Cliente, Atendente e Técnico = PessoasSolicitação, Histórico, Pedido e Pesquisa de Satisfação = DocumentosTelefone = Equipamentos

2.4 DELIMITAR CLASSES REDUNDANTES OU QUE NÃO SÃO NECESSÁRIAS

Podemos observar que Pedido e Solicitação no cenário fazem referência a uma mesma coisa, assim, podemos então eliminar uma das duas. E Telefone é um item de equipamentos, podendo ser eliminado também.

Logo, a lista atualizada ficaria assim:PessoasClienteAtendenteGrupoTécnicoEquipamentoHistóricoCategoriaSubCategoriaItem da categoriaPedidoPesquisa de satisfaçãoSituaçõesTipo de serviçosPrazos

2.5 MONTANDO O DIAGRAMA DE CLASSE

Veja, na figura a seguir, como deve ficar o esboço do Diagrama de Classe.


86

FIGURA 44 – REPRESENTAÇÃO DA MONTAGEM DO DIAGRAMA DE CLASSE

Itens_da_Categoria

- coditem- item

Sub_Categorias- codCategoria- subCategoria

Categorias- codCategoria- categoria

Grupos- codGrupo- codFuncionario

Tipos de Serviços- codTipo

Clientes- codPessoa- numCliente+ setCadastrar ( )+ getConsultar ( )

Atendentes- codPessoa- numAtendente

Técnicos- codPessoa- numTecnico

Pessoas- codPessoa- Pessoa

Documentos- codDoc- documento

Pedidos- codOrdem- codDoc- codCliente- codFuncionario- codGrupo- codTipo- codCategoria- codsubCategoria- codItem

FONTE: O autor

2.6 REALIZANDO AS PRIMEIRAS LIGAÇÕES

Para efetuarmos a primeira ligação, faremos com os objetos que agrupamos por características semelhantes, como, por exemplo: Clientes, Atendentes e Técnicos se relacionam com pessoas; Pedido se relaciona com Documentos. Verifique as ligações:


87

FIGURA 45 – LIGANDO AS CLASSES DE PESSOA

Atendentes- codPessoa- numAtendente


Técnicos- codPessoa- numTecnico

Clientes- codPessoa- numCliente+ setCadastrar ( )+ getConsultar ( )

FONTE: Tacla (2010)

Parte do Diagrama de Classe envolvendo Pedidos e Documentos:

FIGURA 46 - LIGAÇÃO DE PEDIDOS E DOCUMENTOS


Documentos- codDoc- documento

FONTE: Tacla (2010)

Para fazer as ligações, todas as classes devem ser testadas.

Sabemos que o cliente entra em contato com o atendente que gera um pedido. Com esta informação observamos que um pedido foi gerado da interação entre cliente e atendente, onde um cliente pode solicitar vários pedidos para um atendente e um atendente atende a vários clientes. Sua cardinalidade será N para N, onde N quer dizer muitos, sendo: Muitos para Muitos, quando ocorre esse tipo de cardinalidade nasce uma nova tabela ou classe, entre esses dois foi a classe pedidos, que já


88

havíamos identificado antes. O importante sobre a N para N é que a classe que nasceu recebe os códigos da classe que o fez relação, ficando a classe “Pedido” com o código do cliente e o código da atendente. Sabemos também que esse pedido será repassado para um técnico que o atenderá, sendo assim, um técnico pode atender a vários pedidos e um pedido pode ser atendido por um técnico, sendo representado por 1-N, lembrando que a classe que recebe o N herda o campo-chave da outra classe como chave estrangeira, sendo assim ficará a tabela de pedidos com mais um campo, chamado: código do técnico. Faça o processo para todas as classes, use sempre a pergunta dessa forma:Um “Nome de um objeto da classe” pode “nome da ligação (verbo)” um ou vários “nome da classe”Como ficaria entre Pedidos e situação: Um pedido pode ter uma ou várias situações? Resposta: Várias, pois ao abrir está em andamento, em outro ponto do tempo pode ficar pendente e ser concluída ao final do serviço (TACLA, 2010, p. 76).

3 DIAGRAMA DE CLASSE COMPLETO

A figura a seguir mostra como ficaria o diagrama de classe completo, baseado na situação descrita nos itens anteriores.


89

FIGURA 47 – DIAGRAMA DE CLASSE COMPLETO

Equipamentos- codEquipamento

Tipos de Serviços- codTipo

Pedido_Situações- codSituação- codOrdem- tempoNaSituação

Pedido_Equipamentos- codPedido- codEquipamento

Atendentes- codPessoa- numAtendente Grupos

- codGrupo- codFuncionario

Categorias- codCategoria- categoria


Sub_Categorias- codCategoria- subCategoria

Itens_da_Categoria- codItem- Item

Situações- codSituação- situação

Histórico_de_Atendimento- codHistorico- codDoc

Clientes- codPessoa- numCliente+ set1Cadastrat ( )+ getConsultar ( )


Tecnicos- codPessoa- numTecnico

FONTE: Piva (2010)

3.1 DIAGRAMA DE PACOTES

O termo Diagrama de Pacotes é utilizado para descrever um diagrama que mostra pacotes de classes e as dependências entre eles. Este diagrama oferece uma visão do sistema como um todo, sob tal perspectiva que se possa observar todos os subsistemas que o compõem. Tem como proposta apresentar a modelagem estrutural do sistema em divisões lógicas e suas interações em alto nível (SILVA, 2007).


90

• É uma construção de agrupamento que permite a você pegar qualquer construção na UML e agrupar seus elementos em unidades de nível alto.

• Representa um grupo de classes (ou outros elementos) que se relaciona com outros pacotes através de uma relação de dependência.

Os pacotes também podem ser membros de outros pacotes, construindo uma estrutura hierárquica.

• Cada pacote representa um espaço de nomes, o que significa que toda classe deve ter um nome exclusivo dentro do pacote a que pertence. Se eu quiser criar uma classe Date e já existir uma classe Date dentro do pacote System, eu posso ter minha classe Date, desde que a coloque em um outro pacote.

• É um mecanismo de agrupamento geral que serve para agrupar vários modelos.

• Organiza elementos em grupo e costuma ser utilizado na modelagem de sistemas muito extensos.

• São utilizados para demonstrar os limites de cada subsistema e como eles se inter-relacionam.

• Pode conter qualquer diagrama da UML, inclusive outros pacotes. Mais comumente utilizado em Diagrama de Casos de Uso e Diagrama de Classes.

FONTE: Disponível em: <http://200.17.137.109:8081/novobsi/Members/giordano/aulas/2010.2/modelagem-e-programacao-orientada-a-objetos/Diagrama%20de%20Pacotes.pptx.>. Acesso em: 10 out. 2015.

FIGURA 47 – DIAGRAMA DE PACOTES

Sistema Seguradora Sistema Financeiro

FONTE: O autor

3.1.1 Definindo as classes de um Pacote

Para identificar as classes de um pacote, observe o seguinte:

• Classes que estejam na mesma árvore de herança.• Classes que estejam em um mesmo jogo de agregação e composição.• Classes que apareçam em um mesmo Diagrama de Sequência com muitas

colaborações (alto acoplamento).• Um pacote utilitário contém classes sem afinidade direta com o domínio do

problema, porém necessárias.


91

FIGURA 48 – FORMAS DE REPRESENTAR DIAGRAMAS DE PACOTES

Date

java::util

Date

java

util

java::util::Date

util

util

Date

util

Date

Conteúdo listadona caixa

Conteúdo diagramadona caixa

Nome de pacotetotalmente qualificado

Nome de classetotalmente qualificado

Pacotes aninhados

FONTE: O autor

É um diagrama estrutural que permite uma visão da organização interna da aplicação que está sendo projetada.

3.1.2 Principais componentes: pacotes

Verifique outro exemplo de Diagrama de Pacotes na figura a seguir. Um exemplo de pacote que organiza o projeto, pois separa as classes do projeto das interfaces do usuário.


92

FIGURA 49 – COMPONENTES DO DIAGRAMA DE PACOTES

Funcionario

AtendenteDono

Fornece

Caixa

Compra

Cliente Produto ItemFornece

ItemCompra

ItemCompra

GUI

Classes de Projeto

FManutençãoPagamentoCompra

FManutençãoCompra

Floguin

FManutençãoFornece

FONTE: Piva (2010)

93

RESUMO DO TÓPICO 2


• O Diagrama de Classes é possivelmente o diagrama mais utilizado e um dos mais importantes da UML. Serve de apoio para a maioria dos demais.

• É um diagrama que mostra um conjunto de classes, interfaces e colaborações e seus relacionamentos. O Diagrama de Classes é utilizado na construção do modelo de classes desde o nível de análise até o nível de especificação.

• Um diagrama de classes ilustra as especificações para as classes de software e de interface de uma aplicação. Este diagrama mostra definições para entidades de software, e não conceitos do mundo real (LARMAN, 2007). Produz a descrição mais próxima da estrutura do código de um programa, ou seja, mostra o conjunto de classes com seus atributos e métodos e os relacionamentos entre classes. Classes e relacionamentos constituem os elementos básicos do diagrama de classes (SILVA, 2007).

• O diagrama de classes é um dos principais diagramas da UML, representa a estrutura do sistema (elementos que foram selecionados para fazer parte do sistema). A partir dele, por exemplo, o esqueleto do código-fonte pode ser gerado automaticamente.

• O comportamento requerido do sistema é alcançado pela colaboração entre objetos. O Diagrama de Classes fornece uma representação estática da colaboração por meio de relacionamentos. Os relacionamentos são utilizados no Diagrama de Classes que é refinado incrementalmente (modelo do domínio, análise e, posteriormente, no projeto).

• Em programação, um Diagrama de Classes é uma representação da estrutura e relações das classes que servem de modelo para objetos. Podemos afirmar, de maneira mais simples, que seria um conjunto de objetos com as mesmas características, assim saberemos identificar objetos e agrupá-los, de forma a encontrar suas respectivas classes. Na Unified Modeling Language (UML) em Diagrama de Classe, uma classe é representada por um retângulo com três divisões, são elas: O nome da classe, seus atributos e, por fim, os métodos.

• Diagrama de Pacotes é uma construção de agrupamento que permite a você pegar qualquer construção na UML e agrupar seus elementos em unidades de nível alto.

94

• Representa um grupo de classes (ou outros elementos) que se relaciona com outros pacotes através de uma relação de dependência.

• Os pacotes também podem ser membros de outros pacotes, construindo uma estrutura hierárquica.

o Cada pacote representa um espaço de nomes, o que significa que toda classe deve ter um nome exclusivo dentro do pacote a que pertence. Se eu quiser criar uma classe Date e já existir uma classe Date dentro do pacote System, eu posso ter minha classe Date, desde que a coloque em um outro pacote.

o É um mecanismo de agrupamento geral que serve para agrupar vários modelos.

o Organiza elementos em grupo e costuma ser utilizado na modelagem de sistemas muito extensos.

o São utilizados para demonstrar os limites de cada subsistema e como eles se inter-relacionam.

o Pode conter qualquer diagrama da UML, inclusive outros pacotes. Mais comumente utilizado em Diagrama de Casos de Uso e Diagrama de Classes.

95

AUTOATIVIDADE

1 Em relação aos relacionamentos abaixo, responda:

a) Qual a representação mais correta – a primeira ou a segunda relação? Por quê?

Casa

Casa

Pessoa

Pessoa

é propriedade

0..*

0..*1..*

1

+propriedade +proprietário

class Casa

FONTE: Disponível em: <http://www.dainf.cefetpr.br/~tacla/UML/0070-DiagClasses-ExerciciosSol.pdf>. Acesso em: nov. 2015.

b) Qual a diferença de interpretação entre as duas representações? Qual seria a mais indicada para um tribunal eleitoral regional?

class eleições

Pessoaeleitor 0..*

vota>

candidatoPresidente0..1

Pessoaeleitor 0..*

candidatoPresidente0..1

FONTE: Disponível em: <http://www.dainf.cefetpr.br/~tacla/UML/0070-DiagClasses-ExerciciosSol.pdf>. Acesso em: nov. 2015.

2 Represente um e-mail na forma de Diagrama de Classes. Identifique os componentes (destinatário, assunto etc...) e suas relações.

3 Qual a diferença de interpretação entre os relacionamentos livro-sobrecapa e livro-páginas?

96

Livro Pagina Paragrafo

SobreCapa0..1

1...* 1...*

4 Todo aluno matriculado em trabalho de diplomação será orientado por um professor. Alguns professores orientam vários alunos e outros, nenhum. Qual dos diagramas melhor representa esta relação?

Aluno

Aluno

Prof

Prof

Aluno Prof

Aluno Prof

1

11

10..*

0..*

orientador

orientadororientador

orientador

a) c)

d)b)0..*

0..*

5 Construa a hierarquia de classes para os seguintes tipos de obras: romance, livro de ficção, livro de autoajuda, gibi, rock, filme ficção, comédia e MPB.

6 Defina pacotes.

97

TÓPICO 3

DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE

COMPONENTES

UNIDADE 2

1 INTRODUÇÃO

Este diagrama está amplamente associado ao Diagrama de Classes.

Na verdade, o Diagrama de Objetos é praticamente um complemento do Diagrama de Classes, sendo bastante dependente deste. O Diagrama de Objetos fornece uma visão dos valores armazenados pelos objetos de um Diagrama de Classes em um determinado momento da execução de um processo.

De acordo com Guedes (2011), o Diagrama de Objetos está amplamente associado ao Diagrama de Classes, podendo ser visto como uma instância de tal diagrama, assim como os objetos são instâncias de classes. Tal qual o Diagrama de Classes, o Diagrama de Objeto é formado por estruturas estáticas. Bezerra (2007) diz que um Diagrama de Objetos exibe uma fotografia do sistema em um determinado momento, exibindo ligações formadas entre objetos conforme interação entre eles e de acordo com valores de atributos.

Os Diagramas de Objetos abrangem a visão estática de projeto ou visão estática de processo de um sistema (BOOCH; RUMBAUGH; JACOBSON, 2005).

2 PRINCIPAIS COMPONENTES: OBJETOS, RELACIONAMENTOS

Este diagrama nos dá uma visão de como ficarão os objetos em determinado momento da execução do sistema. É como se tirássemos uma fotografia do sistema em um momento para analisar os dados e os relacionamentos envolvidos.

98


FIGURA 50 – DIAGRAMA DE OBJETOS

fornec:Fornece- dataEntrada: 27/10/2009- nroNF=123- valorTotal=483.17- lancadoPor=func- dataLancamento= 27/10/2009- horaLancamento=11:35- fornecedor=forn

fornec:Fornece- codigo=46- nome=Fulano de Tal Ltda- cnpj=12.345.678/ 0009-10

cart:Cartao- nroCartao=123- datainicioUso= 23/12/208- dataFimUso=null

prod:Produto- codigo:|- d- descricao=Leite: Tipo A- quantidadeEstoque=38- vllUnitarioVenda= 2.65- estoqueMinimo= 30.00- situacao=|

func:Funcionamento- cpf=123.456.789-01- nome=Olavo Petronio Caz- nroCarteiraProfissional = 12345- dataAdmissão= 13/05/1991- dataDemissao=null- senha=******

itl:llemFornece- produto=prod- quantidade=4.00- valorUnitario=2.83

comp:Compra- dataCompra= 27/10/2009- valorTotal=12.80- terminada=true- recebidoPor=func

itl:llemCompra- qualidade=3.00- data Registro= 27/10/2009- horaRegistro=12:05- atendidoPor.func- cliente=cart

FONTE: Piva (2010)

Observe a notação desse diagrama: o objeto possui a mesma estrutura de uma classe, porém seu nome vem antes do nome da classe. func: Funcionario quer dizer objeto func da classe funcionário.

Podemos assim analisar as relações entre os objetos em um determinado ponto da execução do sistema.

TÓPICO 3 | DIAGRAMAS ESTRUTURAIS: DE OBJETOS E DE COMPONENTES

99

3 DIAGRAMA DE COMPONENTES

Booch, Rumbaugh e Jacobson (2005) narram que um Diagrama de Componentes mostra a organização e as dependências entre os vários componentes de um sistema. Um componente representa um módulo físico do código. As dependências entre os componentes mostram como mudanças em um componente podem causar mudanças em outros componentes. Este diagrama fornece uma visão modelada entre os módulos do próprio código-fonte, bibliotecas e formulários, arquivos de banco de dados e demais arquivos de sistema. Além de determinar como cada um desses elementos estará disposto na organização do sistema e como interagem entre si (GUEDES, 2011). Mostra a organização e as dependências existentes em um conjunto de componentes; os diagramas de componentes abrangem a visão estática de implementação de um sistema (BOOCH; RUMBAUGH; JACOBSON, 2005).

O Diagrama de Componentes é um diagrama estrutural que nos ajuda a analisar as partes do sistema que podem ser substituídas por outras que implementem as mesmas interfaces (de entrada e/ou de saída) sem alterar o seu funcionamento.

3.1 PRINCIPAIS COMPONENTES: COMPONENTES, INTERFACES, CLASSES E RELACIONAMENTOS

Todo componente, geralmente, pode ser substituído por uma classe, que implementa suas interfaces. Por isso é bastante difícil separar um do outro. Mas costumamos utilizar o Diagrama de Componentes quando precisamos documentar um componente que pode ser substituído no sistema.

Um claro exemplo de uso de componente e, consequentemente, do Diagrama de Componentes no estudo de caso da padaria do senhor João, é a representação da balança que pesa os produtos comercializados na padaria.

Como a balança vai interagir com os componentes do software, alimentando o sistema com informações sobre o produto vendido, como peso e valor, o senhor João poderá substituir a balança apenas por outra que possibilite as mesmas interfaces, tanto de entrada quanto de saída.

FONTE: Disponível em: <http://dicasdeinformatica.xyz/diagramas-uml/>. Acesso em: nov. 2015.

100


FIGURA 51 – COMPONENTES DO DIAGRAMA DE PACOTES

itemCompraBalançaProduto

Código do produtoe preço por quilo

Código do produto,quantidade comparada

e preço por quilo.

BalançaProduto BalançaItemCompraFONTE: Piva (2010)

Podemos aproveitar e defi nir as interfaces de entrada e saída da balança e deixá-las documentadas nesse diagrama.

3.1.1 Componente

É uma parte do sistema que é física e substituível e que está em conformidade com um conjunto de interfaces (fornecidas e/ou requeridas). Um componente é parte do sistema e é reutilizável.

Os diagramas de componentes capturam a estrutura física da implementação.

3.1.2 Objetivos

• Organizar o código-fonte (ambiente de desenvolvimento).• Construir um release executável (ambiente de produção).• Especifi car componentes como base de dados etc. • Contém componentes, interfaces e relações entre componentes.• Os pacotes de componentes podem ser utilizados para modelar a arquitetura

física.• Identifi car as principais peças do sistema.

Um pedaço de software reutilizável, bem encapsulado e “facilmente” substituível.

• São blocos (peças) que combinados constroem o sistema pretendido. • A dimensão dos componentes não é homogênea, existindo, num mesmo

sistema, componentes de diferentes dimensões. • Quais são os bons candidatos a serem componentes do sistema? • Itens que desempenham uma funcionalidade que é utilizada recorrentemente

no sistema. Exemplos: componentes de logging, parsers de XML, componentes de gestão de carrinhos de compra (shopping carts) etc.


101

• Em UML um componente pode efetuar as mesmas funcionalidades que uma classe faz:

o Generalização o Associação com outros componentes ou classes o Implementação de interfaces

• Um componente representa um empacotamento físico de elementos relacionados logicamente (normalmente classes).

FONTE: Disponível em: <http://slideplayer.com.br/slide/1584624/>. Acesso em: nov. 2015.

Os componentes existem no mundo material, de bits. São um elemento importante na modelagem dos aspectos físicos de um sistema. Um componente é uma parte física e substituível de um sistema, que realiza um conjunto de interfaces. Exemplos de componentes são código-fonte, executáveis, bibliotecas, tabelas, arquivos e documentos. Um componente, tipicamente, é uma versão física de elementos lógicos, como classes e interfaces. Disponível em:<http://www.cin.ufpe.br/~eng_soft/eti901/NotasdeAulas/a8_1-UMLImplementacao.pdf>. Acesso em: nov. 2015.

Diagramas de componentes são usados para modelar os aspectos físicos de um sistema: o código-fonte de um aplicativo, uma API etc. Nos Diagramas de Componentes são mostrados componentes e os relacionamentos entre eles. Dependências entre componentes são mostradas. A única restrição é que o que está sendo modelado deve ser físico (formado por bits) e não conceitual (ou lógico). Disponível em: <http://slideplayer.com.br/slide/3691521/>. Acesso em: nov. 2015.

Na UML 2

• Uma parte modular de um sistema que encapsula seu conteúdo e cuja manifestação seja substituível dentro de seu ambiente.

• Um componente define seu comportamento em termos de interfaces fornecidas e requeridas.

3.1.3 Diagrama de Componentes

• Especificação de um conjunto de componentes e suas interdependências.• Representam de forma estática aspectos físicos do sistema que está sendo

modelado.• São importantes para visualizar, especificar e documentar sistemas baseados

em componentes.• Eles mostram um conjunto de componentes e seus relacionamentos.• São tipicamente usados para:

102


o Modelar a organização do código-fonte.o Modelar lançamento de executáveis (release).o Modelar fisicamente um banco de dados.o Modelar sistemas adaptativos. o Modelar a organização do código-fonte.

• Na implementação das classes definidas durante a modelagem, o código gerado será armazenado fisicamente em arquivos, o Diagrama de Componentes serve como forma de gerenciamento destes arquivos.

o Modelar lançamento de executáveis (releases).

• Uma versão de um sistema envolve combinações específicas de diversas partes. O Diagrama de Componentes pode modelar os diversos componentes necessários para uma determinada versão do sistema.

o Modelar fisicamente um banco de dados.

• Considerando-se que as informações do sistema serão armazenadas em arquivos ou tabelas de um banco de dados, um Diagrama de Componentes pode mostrar os arquivos (ou tabelas) do banco de dados e seus relacionamentos.

o Modelar sistemas adaptativos.

• A execução de alguns sistemas baseia-se no uso de componentes dinâmicos (carga dinâmica, agentes móveis etc.), que podem ser descritos através de um Diagrama de Componentes conjuntamente com outros diagramas da UML.

• O principal elemento sintático deste diagrama é o componente.• O principal objetivo deste diagrama, segundo Scott Ambler, é possibilitar a

construção de artefatos para o perfil de arquitetura da solução, seja para a arquitetura técnica ou a de negócios.

FONTE: Disponível em: <https://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiVn9CI2J_JAhVGPZAKHSE2AwUQFggeMAA&url=http%3A%2F%2F200.17.137.109%3A8081%2Fnovobsi%2FMembers%2Fgiordano%2Faulas%2F2010.2%2Fmodelagem-e-programacao-orientada-a-objetos%2FDiagrama%2520de%2520Componentes.pptx&usg=AFQjCNHjrdTLZ5fjTY_uQhdE5xZC1z0nIA>. Acesso em: nov. 2015.


103


Uma reflexão sobre Banco de Dados Orientados a Objetos

Clodis BoscarioliAnderson Bezerra

Marcos de BenedictoGilliard Delmiro

Até meados dos anos 60, os dados eram mantidos aleatoriamente em arquivos, geralmente como partes integrantes da aplicação. A partir dessa época, surgiram os primeiros Sistemas Gerenciadores de Bancos de Dados (SGBDs) comerciais, provendo armazenamento dos dados de forma independente da aplicação, contudo, sem mecanismos de acesso eficientes.

Codd (1970) propôs a criação de linguagens de alto nível, permitindo manipulação eficiente. A partir dos anos 80 as aplicações computacionais evoluíram, juntamente com o poder de processamento das máquinas, surgindo a necessidade de tratar dados mais complexos, não convencionais. Devido a esse aumento na complexidade dos dados, surgiu a necessidade de formas mais adequadas de representação e armazenamento, como as bases de dados orientadas a objetos.

Durante a década de 80, como resultado das inovações de hardware, emergiram novas aplicações com utilização intensiva de dados. Para essas aplicações, os modelos de dados tradicionais, baseados no modelo relacional, não eram adequados. Alguns exemplos de aplicações desse tipo incluem sistemas de design e produção, como CAD (Computer-Aided Design) e CAM (Computer-Aided Manufacturing), sistemas para as áreas científica e médica, sistemas de informação geográfica e bases de dados com informações multimídia. Essas aplicações possuem requisitos e características, tais como dados altamente estruturados, transações longas, dados em multimídia e operações fora do padrão, específicas da aplicação, que as tornam diferentes das aplicações tradicionais (CHAUDRI & ZICARI, 2001, p. 3).

Silberchatz et al. (2001, p. 307) afirmam que:

À medida que as bases de dados foram sendo utilizadas em um âmbito maior de aplicações, as limitações impostas pelo modelo relacional emergiram como obstáculos. Como resultado, pesquisadores da área de bancos de dados inventaram novos modelos de dados que superassem as restrições do modelo relacional. [...] Nos últimos anos a demanda por maneiras de tratar dados mais complexos tem crescido.

Existe um grande interesse relativo às tecnologias orientadas a objetos na

comunidade de desenvolvimento de software, sobretudo no tocante à facilidade de alteração de implementações de acordo com mudanças solicitadas nos requisitos.

104


A capacidade que esse paradigma possui de representar dados complexos uniu-se à tecnologia de banco de dados, gerando os Bancos de Dados Orientados a Objeto (BDOO), que suportam modelagem e criação de dados como objetos (ODBMS, 2006). O objetivo desse artigo é prover uma visão geral sobre sistema de BDOO, uma tecnologia não tão nova (BANCIIHON, 1988; ATKINSON, et al., 1989), contudo considerada ainda pouco explorada. Para tal, está organizado como segue: Conceitos básicos sobre Banco de Dados Relacionais (BDR) e BDOO são abordados na Seção 2. A Seção 3 diz respeito à modelagem no paradigma orientado a objetos, mostrando como um mesmo modelo pode ser usado em ambas as camadas, de banco de dados e da aplicação.

2 Bancos de Dados Relacionais versus Bancos de Dados Orientados a Objetos

BDRs e BDOOs possuem características distintas, mas basicamente servem ao mesmo propósito: persistir dados necessários para a manutenção do negócio para o qual são aplicados, possibilitando a recuperação, comparação e tratamento desses dados a fim de produzir resultados tangíveis. Em BDR, uma coleção de tabelas, todas com nomes únicos, compõe a base de dados, podendo estar relacionada a uma ou mais tabelas. Conceitos como integridade referencial de dados – que garantem que um dado referenciado em uma tabela esteja presente na tabela que está sendo referenciada – e chaves primárias estão presentes e garantem que um conjunto de informações possa ser representado de maneira consistente, independente da forma de acesso.

Já um BDOO possui três pilares principais: herança, polimorfismo e encapsulamento, discutidos a seguir. Este modelo apresenta maior flexibilidade na manipulação de seu conteúdo e, por meio de identificadores de objetos, manipula os dados de forma consistente. Silbeschatz et al. (2001) concluem que as bases de dados tradicionais são bastante eficientes para tarefas ligadas ao processamento de dados. A geração de folhas de pagamento e o gerenciamento de contas correntes são exemplos. Esse tipo de aplicação trabalha basicamente com tipos de dados simples: numéricos, texto e datas. Além disso, essas aplicações possuem itens de dados que podem ser representados como registros razoavelmente pequenos e campos atômicos.

Apesar do conceito de bancos de dados orientados a objetos ser bastante distinto do modelo relacional, o mesmo resulta da integração entre a orientação a objetos e a tecnologia de banco de dados tradicionais. Enquanto na programação orientada a objetos, os objetos existem apenas enquanto o programa que os criou está em execução, os bancos de dados orientados a objetos podem criar objetos que sejam persistentes e compartilhados entre diferentes aplicativos.

[...]

4 Principais SGBDOOs no Mercado Atual

Os sistemas gerenciadores de bancos de dados orientados a objetos não possuem grandes discrepâncias em termos de funcionalidades exigidas quando relacionados aos SGBDs relacionais. Entretanto, torna-se necessário levantar

105

alguns pontos de diferenciação. Uma das principais exigências de um SGBDOO é o armazenamento de objetos e suas operações de forma a prover uma integração transparente com a aplicação, sem a necessidade de uma camada de tradução dos dados. A Tabela 1 traz uma comparação entre três grandes SGBDOOs disponíveis no mercado, o Objectivity/DB, o GemStone e o Jasmine, evidenciando que suas funcionalidades não diferem muito com relação aos aspectos mais importantes dos SGBDOOs.

Para Chaudri & Zicari (2001), a oferta de SGBDOOs tem aumentado, principalmente, como consequência do crescimento da utilização da plataforma Java. O mesmo afirmam Dan Lo et al. (2002). Segundo estes autores, o impacto desta linguagem de programação no mundo dos SGBDOOs tem sido considerável e diversos SGBDOOS realizaram modificações para oferecer suporte nativo para o armazenamento de objetos Java. Ferramentas como POET e ObjectStore, inicialmente desenvolvidas para persistência de objetos C++, disponibilizaram versões com capacidade de persistir objetos Java. Como resultado do aumento da popularidade do desenvolvimento de sistema em Java, a segunda versão do padrão ODMG adicionou elementos de ligação Java. Isto também refletiu em algumas mudanças no modelo de objetos, como a noção de interface e a introdução de dois tipos diferentes de hierarquias.

Principais SGBDOOOs do mercado

Nome Open Source

Sistema Operacional Fabricante Site Oficial

EntrepriseDB SIMLinux, MacOs,

Solaris e Windows

EnterpriseDB http://www.enterprisedb.com/

Objectivity/DB NÂOLinux,

Windows e Unix Posix

Objectivity Database Systems

http://www.objectivity.com

GemStone NÂO WIndows, UNIX e Linux

GemStone System Inc. http://www.gemsotne.com

ConteXT NÃO WIndows e UNIX Unixspace http://www.contextsoft.com/

Versant NÃO Windows, Linux e UNIX Versant Corp. http://www.versant.com

Caché NÃO Windows, Linux e UNIX

Intersystems Software http://www.intersystems.com.br

EyeDB SIM Linux e UNIX Sysra Informatique http://www.eyedb.org/

Jasmine NÃO Windows, Linux e UNIX

Computer Associates http://www.3.ca.com/

ORION SIM Linux e UNIXOrion Group

(Purdue University)

http://orion.cs.purdue.edu/

ObjectStore NÃO Windows, Linux e UNIX

Progress Software http://www.objectstore.com

106

5 Tendências

Algumas tendências referentes à orientação a objetos aplicada a bancos de dados estão sendo discutidas há certo tempo, sem terem amadurecido muito nesse período. Existe hoje a possibilidade de avaliar quais tendências serão de fato concretizadas, levando em consideração o histórico da tecnologia? Entre as tendências emergentes neste contexto está o armazenamento em memória. Um exemplo de armazenamento em memória é o Prevayler (2006).

Produzido independentemente por um grupo de brasileiros, essa ferramenta consiste em um repositório de objetos com desempenho de acesso bastante superior aos bancos de dados tradicionais, principalmente pela característica de manter os objetos em memória no servidor de aplicações. Essa tecnologia ainda tem limitações, principalmente ligadas à recuperação dos dados em caso de falha e aumento da necessidade de memória. Existem, e bem aceitos no mercado atual, os sistemas de banco de dados objeto-relacionais. Estes podem ser vistos como uma tentativa de estender sistemas de banco de dados relacionais com funcionalidades dos bancos de dados orientados a objetos, necessárias para dar suporte a uma classe mais ampla de aplicações e, de certa forma, prover uma ligação entre esses paradigmas.

Além dos sistemas gerenciadores de banco de dados objeto-relacionais, como Oracle (2006) e PostgreSQL (2006), já bastante difundidos no mercado, outra tendência são as interfaces objeto-relacionais que consistem em uma abstração do modelo relacional para uma camada que provê interface de banco de dados orientado a objetos para uma aplicação e pode ser exemplificada por ferramentas como o Hibernate (2006). Essa tecnologia permite que as aplicações persistam os dados de forma transparente em quaisquer tipos de bancos, inclusive arquivos-texto, cuidando de toda a complexidade inerente à tarefa.

Para a aplicação é como se existisse um banco de dados orientado a objeto servindo de repositório. As novas arquiteturas orientadas a serviço, como a SOA (Service Oriented Architecture) (GUPTA, 2005; COHEN, 2006), também estão forçando os desenvolvedores a produzirem sistemas com um aproveitamento cada vez maior de componentes e, consequentemente, com menor acoplamento. Por esse motivo, as bases de dados relacionais, onde até o momento os dados são persistidos, deixam de atender a esse tipo de requerimento, tornando as bases de dados orientadas a objetos uma escolha mais interessante para uma escala ainda maior de aplicações.

Com isso, a possibilidade do surgimento de novas tecnologias ligadas ao paradigma da orientação a objeto, que tenham como missão auxiliar na persistência dos dados de cada um dos objetos, tende a crescer nos próximos anos.

107

RESUMO DO TÓPICO 3


• O Diagrama de Objetos está amplamente associado ao Diagrama de Classes. Na verdade, o Diagrama de Objetos é praticamente um complemento do Diagrama de Classes, sendo bastante dependente deste.

• Os Diagramas de Objetos abrangem a visão estática de projeto ou visão estática de processo de um sistema.

• Este diagrama nos dá uma visão de como ficarão os objetos em determinado momento da execução do sistema.

o Principais componentes: objetos, relacionamentos.

• O Diagrama de Componentes é um diagrama estrutural que nos ajuda a analisar as partes do sistema que podem ser substituídas por outras que implementem as mesmas interfaces (de entrada e/ou de saída) sem alterar o seu funcionamento.

o Principais componentes: componentes, interfaces, classes e relacionamentos. o Objetivos: o Organizar o código-fonte (ambiente de desenvolvimento). o Construir um release executável (ambiente de produção). o Especificar componentes como base de dados etc. o Contém componentes, interfaces e relações entre componentes. o Os pacotes de componentes podem ser utilizados para modelar a arquitetura física. o Identificar as principais peças do sistema.

108

1 Defina Componente.

2 Quais as vantagens/motivações para a construção de modelos de componentes?

3 Defina Diagrama de Objetos.

AUTOATIVIDADE

109

UNIDADE 3

DIAGRAMAS ESTRUTURAIS


PLANO DE ESTUDOS

Ao final desta unidade você será capaz de:

• conhecer os diagramas estruturais de implantação e estrutura composta;

• ter uma visão da integração dos diagramas;

• conhecer as principais ferramentas UML.

Esta unidade de ensino contém três tópicos e no final de cada um deles você encontrará atividades que contribuirão para a apropriação dos conteúdos.

TÓPICO 1 – DIAGRAMAS DE IMPANTAÇÃO E ESTRUTURA COMPOSTA

TÓPICO 2 – INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO DESENVOLVIMENTO USANDO UML

TÓPICO 3 - ESTUDO DE CASO

111

TÓPICO 1

DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA

UNIDADE 3

1 INTRODUÇÃO

Os Diagramas de Implantação mostram a topologia do sistema em tempo de execução, representando a configuração e a arquitetura do mesmo em relação aos seus componentes (BOOCH; RUMBAUGH; JACOBSON, 2006). Ainda, na percepção dos autores, este tipo de diagrama modela a visão estática da implantação do sistema, expressando o conjunto de hardware e demais tecnologias físicas relacionadas com sua instalação. Também podem ser usados para especificar os módulos do sistema que deverão ser instalados no cliente.

Estes diagramas são compostos por nós e associações, mais conhecidos como relacionamentos de comunicação. Os nós podem ser reconhecidos como sendo um computador, uma rede, um HD. Diagramas de Implantação são mais utilizados por equipes de desenvolvimento, integração e testes. Também são usados para mapear os programas que são executados em cada computador.

FIGURA 52 – EXEMPLO DE DIAGRAMA DE IMPLANTAÇÃO

FONTE: Disponível em: <http://www.cin.ufpe.br/~eng_soft/eti901/NotasdeAulas/a8_1-UMLImplementacao.pdf:>. Acesso em: 20 out. 2015.

UNIDADE 3 | DIAGRAMAS ESTRUTURAIS

112


FONTE: Disponível em: <http://www.cin.ufpe.br/~eng_soft/eti901/NotasdeAulas/a8_1-UMLImplementacao.pdf:> Acesso em: 20 out. 2015.

2 PRINCIPAIS COMPONENTES

Os nós podem representar dispositivos computacionais, como um computador ou um celular, ou um recurso de computação, como um sistema operacional, quaisquer outros softwares que integrem a estrutura da aplicação. Possuem um nome e podem receber um estereótipo. Um nó é representado por um cubo. Os nós executam os artefatos.

Uma associação entre dois nós representa uma conexão física entre os nós, como uma conexão Ethernet, uma linha serial ou um link de satélite.

Artefatos são os elementos executados pelos nós, geralmente os programas da solução criada possuem um nome e podem possuir um estereótipo. Os relacionamentos são utilizados para representar o tipo de ligação entre os componentes do diagrama. Podem possuir estereótipos.

Veja que, na figura a seguir, demonstramos em detalhes a arquitetura da solução proposta.

TÓPICO 1 | DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA

113


<<sevidor>>servidor web

<<banco operacional>>:Linux<<banco de aplicação>>:Apache

<<web container>>:Tomcat

<<artefato>>:vendeTudo.war

<<navegador web>>:Internet Explorer

Computador Cliente

<<servidor>>Servidor de Banco de Dados

<<sistema operacional>>:windows server

<<banco de dados>>:SQLServer

<<artefato>>:vendeTudoBD

<<10-T Ethernet>>

<<HTTP>>

FONTE: Piva (2010)

3 DIAGRAMA DE ESTRUTURA COMPOSTA

O Diagrama de Estrutura Composta é utilizado para modelar colaborações. Uma colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas por instâncias que cooperam entre si para executar uma função específica.

O termo estrutura se refere à composição dos elementos estruturais interconectados de forma a atingir algum objetivo comum. O exemplo acima mostra como as instâncias das classes autor, submissão, tema e tipo colaboram entre si para submeter à submissão. As colaborações podem também possuir multiplicidade, se as regras seguidas pelas classes utilizarem múltiplas instâncias. Este é um diagrama que não é muito utilizado na UML e provavelmente é mais um diagrama teórico do que um diagrama utilizado nos processos de desenvolvimento.

FONTE: Disponível em: <http://www.novatec.com.br>. Acesso em: 5 nov. 2015.


114

Nos modelos UML, um Diagrama de Estrutura Composta mostra a estrutura interna dos classificadores estruturados utilizando peças, portas e conectores. Um classificador estruturado define a implementação de um classificador e pode incluir uma classe, um componente ou um nó de implementação. Você pode utilizar o Diagrama de Estrutura Composta para mostrar os detalhes internos de um classificador e descrever os objetos e funções que trabalham juntos para executar o comportamento do classificador contido.

FONTE: Disponível em: <http://www.novatec.com.br>. Acesso em: 5 nov. 2015.

Um Diagrama de Estrutura Composta é similar a um Diagrama de Classes, mas ele representa peças individuais em vez de classes inteiras. Antes de definir a estrutura interna de um classificador, você deve mostrar seu compartimento de estrutura ou abrir um Diagrama de Estrutura Composta. Então, você pode modelar as peças que representam as instâncias que o classificador contido possui. Você pode incluir conectores para vincular duas ou mais peças em um relacionamento de associação ou dependência.

Em Diagramas de Estrutura Composta, as portas definem o ponto de interação entre um classificador e seu ambiente ou entre um classificador e suas peças internas. Você pode utilizar uma porta para especificar os serviços que um classificador fornece e requer de seu ambiente.

Você também pode modelar colaborações e usos de colaborações em Diagramas de Estrutura Composta. Uma colaboração descreve as funções e os atributos que definem um comportamento específico do classificador. Um uso de colaboração representa um uso específico da colaboração para explicar os relacionamentos entre as propriedades de um classificador. Para identificar as funções das peças no uso de colaboração, você anexa um uso de colaboração a uma colaboração e, em seguida, inclui o uso de colaboração em um diagrama de estrutura composta.

FONTE: Disponível em: <http://www-01.ibm.com/support/knowledgecenter/SS5JSH_9.1.1/com.ibm.xtools.modeler.doc/topics/ccompstruc.html?lang=pt-br>. Acesso em: nov. 2015.

Os seguintes tópicos descrevem elementos de modelo em Diagramas de Estrutura Composta:

Peças

Em Diagramas de Estrutura Composta, uma peça é um elemento de diagrama que representa um conjunto de uma ou mais instâncias que um classificador estruturado contido possui. Uma peça descreve a função de uma instância em um classificador. Você pode criar peças no compartimento de estrutura de um classificador e em vários diagramas UML, como estrutura composta, classe, objeto, componente, implementação e Diagramas de Pacote.

TÓPICO 1 | DIAGRAMA DE IMPLANTAÇÃO E ESTRUTURA COMPOSTA

115

Portas

Em Diagramas de Estrutura Composta, uma porta define o ponto de interação entre uma instância do classificador e seu ambiente ou entre o comportamento do classificador e suas peças internas.

Colaborações

Nos diagramas UML, uma colaboração é um tipo de classificador estruturado no qual as funções e atributos cooperam para definir a estrutura interna de um classificador. Você utiliza uma colaboração quando deseja definir apenas as funções e conexões que são requeridas para executar um objetivo específico da colaboração. Por exemplo, o objetivo de uma colaboração pode definir as funções ou os componentes de um classificador. Ao isolar as funções principais, uma colaboração simplifica a estrutura e esclarece o comportamento em um modelo.

Usos de Colaboração

Nos Diagramas de Estrutura Composta, um uso de colaboração é um elemento de modelo que representa um uso de uma colaboração para explicar os relacionamentos entre as partes de um classificador estruturado. Você utiliza um uso de colaboração para aplicar um padrão, que é descrito por uma colaboração, para uma situação específica que envolve classes ou instâncias que desempenham as funções de colaboração especificadas. Você pode ter vários usos de colaboração, cada um envolvendo um conjunto diferente de funções e conectores para uma colaboração determinada.

Conectores em Classificadores Estruturados

Em diagramas UML, um conector é uma linha que representa um relacionamento em um modelo. Ao modelar a estrutura interna de um classificador, você pode utilizar um conector para indicar um link entre duas ou mais instâncias de uma peça ou porta. O conector define o relacionamento entre os objetos ou instâncias que são ligados a funções no mesmo classificador estruturado e identifica a comunicação entre essas funções. O produto especifica automaticamente o tipo de conector a ser criado

FONTE: Disponível em: <http://www-01.ibm.com/support/knowledgecenter/SS5JSH_9.1.1/com.ibm.xtools.modeler.doc/topics/ccompstruc.html?> Acesso em: 21out. 2015.


116

FIGURA 55 – EXEMPLO DE DIAGRAMA DE ESTRUTURA COMPOSTA

controles:ApresentadordeTV

:Gerador [1]

multiplicidade

conector de delegação

IU do controle da TV

API do controle da TV

Visualizadorde TV

tela

fluxo de imagenssintonia

parte

conector

1

FONTE: Disponível em: <http://regissimao.com.br/wp-content/uploads/2014/03/UML-08-Diagrama-de-Estruturas-Compostas.pdf>. Acesso em: 23 out. 2015.

117


• O Diagrama de Implantação representa a configuração e a arquitetura do sistema em que estarão ligados os respectivos componentes. Booch, Rumbaugh e Jacobson (2006) dizem que este diagrama exibe a configuração dos nós de processamento em tempo de execução e os componentes que nele existem.

• Neste diagrama também pode ser representada toda a estrutura de hardware e requisitos mínimos onde o sistema será executado. Este diagrama modela a visão estática da implantação de um sistema. Dado um determinado sistema de software, o Diagrama de Implantação vai expressar o conjunto de hardware e toda a tecnologia física relacionada com a instalação do sistema. Os Diagramas de Implantação também podem ser usados para especificar os módulos do sistema que deverão ser instalados no cliente.

• São usados para modelar a topologia do ambiente no qual o software será executado.

• São compostos por nós e associações (relacionamentos de comunicação).

• Um nó pode ser, por exemplo, um computador, uma rede, um disco rígido, um sensor etc. Usado para as equipes de: desenvolvimento, integração e testes. Também mapeiam como os componentes são distribuídos na arquitetura física.

• O Diagrama de Estrutura Composta é utilizado para modelar colaborações. Uma colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas por instâncias que cooperam entre si para executar uma função específica.

• O termo estrutura se refere à composição dos elementos estruturais interconectados de forma a atingir algum objetivo comum. O exemplo acima mostra como as instâncias das classes autor, submissão, tema e tipo colaboram entre si para submeter à submissão. As colaborações podem também possuir multiplicidade, se as regras seguidas pelas classes utilizarem múltiplas instâncias. Este é um diagrama que não é muito utilizado na UML e provavelmente é mais um diagrama teórico do que um diagrama utilizado nos processos de desenvolvimento.

RESUMO DO TÓPICO 1

118

1 É empregado para a modelagem dos aspectos físicos de um sistema OO. Mostra a configuração dos nós de processamento em tempo de execução e os artefatos que nele existem. Trata-se do diagrama de:

a) Comunicaçãob) Componentesc) Implantaçãod) Estrutura Composta

FONTE: Disponível em: <https://www.qconcursos.com/questoes-de-concursos/questao/22be5843-46>. Acesso em: nov. 2015.

2 Considere C = comportamental e E = estrutural. Os diagramas de componentes, objetos, comunicação e estrutura composta são, respectivamente, categorizados como:

a) C; C; E; Cb) C; C; E; Ec) E; E; C; Ed) E; E; C; C.

FONTE: Disponível em: <https://www.qconcursos.com/questoes-de-concursos/questao/22be5843-46>. Acesso em: nov. 2015.

AUTOATIVIDADE

119

TÓPICO 2

INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO

DESENVOLVIMENTO USANDO UML

UNIDADE 3

1 INTRODUÇÃO

Neste tópico, será apresentada uma situação real tendo como cenário uma padaria. Com isso, será possível visualizar de forma bem clara a interação de vários diagramas e a sequência de criação dos mesmos.

2 EXEMPLO DE DESENVOLVIMENTO DE PROJETOS USANDO UML

Geralmente, desenvolvemos os diagramas de casos de uso para agrupar as funcionalidades mais importantes a serem implementadas. Sobre tais funcionalidades criamos o Diagrama de Classes, que será a estrutura de nossa aplicação ou o que chamamos de classes de projeto. No caso de uma padaria, por exemplo, as classes de projeto são as classes de cliente, produto, funcionário, compra, fornece e suas classes filhas.

Definimos seus principais atributos e então fazemos o Diagrama de Sequência para os casos de uso mais relevantes – no exemplo da padaria, os casos de uso registrar compra, pagar compra, receber mercadoria. Usamos esse diagrama para definir os principais métodos de nossas classes e as trocas de mensagens entre elas. Com isso definido, voltamos ao Diagrama de Classes e o complementamos com os métodos definidos nos Diagramas de Sequência.

Começamos então a nos preocupar com a interface e com o usuário e escolhemos quais formulários serão necessários para o funcionamento de nossa aplicação. Com as classes definidas, começamos a separá-las para melhor organizar a aplicação.

Utilizamos para isso o padrão MVC. Esse padrão, muito utilizado pelos desenvolvedores orientados a objeto, foi criado com a linguagem de programação Smalltalk80. Consiste basicamente em dividir as classes da aplicação em três grupos, que chamamos de model, view e controller. Criamos um pacote para cada um desses itens. No model, em geral, inserimos as classes de projeto, seguindo o modelo de nossa aplicação.

120


No view criamos as classes de interface com o usuário (telas) e no controller inserimos as classes que implementarão as funcionalidades de cada classe, desde uma simples consistência até o acesso ao banco de dados. Essas classes que implementam o acesso ao banco de dados levam o nome de classes de persistência, muitos desenvolvedores as colocam em outro pacote.

Dentro do view voltamos a separar as classes em pacotes para implementar a modulação do sistema, criando pacotes para cadastro, movimentação, consultas, relatórios e demais rotinas da execução do sistema, às quais chamamos de ferramentas. Com isso organizamos internamente as classes nos mesmos padrões utilizados na aplicação.

Terminada a separação das classes, criamos os diagramas de atividade para os casos de uso cujo procedimento e funcionamento pretendemos deixar documentados.

Verificamos então se é necessário documentar as interfaces de algum componente de software e elaboramos diagramas de componentes para isso. Se houver classes que mudam de estado no decorrer da execução do sistema, desenvolvemos o Diagrama de Máquinas de Estados para demonstrar qual a ideia da mudança de estado para cada uma delas.

Por fim, se o ambiente de implantação for um ambiente heterogêneo, isto é, que envolve arquitetura com vários servidores, como servidor de banco de dados e servidor de aplicações, entre outros, criamos o Diagrama de Implantação para demonstrar a arquitetura de software e hardware onde a aplicação deverá ser instalada.

Veja que nessa forma de desenvolvimento utilizamos os diagramas de casos de uso, os de classes, os de sequência, os de pacotes, os de atividades, os de máquina de estados, os de componentes e o de implantação. Tudo depende do tamanho da aplicação a ser desenvolvida e das dificuldades que encontramos nas fases de análise e projeto de software.

É comum também surgirem alterações nos modelos na fase de programação do software. Nesse caso, voltamos ao modelo e incluímos as alterações que fizemos na fase de programação e testes. Mesmo depois de implantada a solução, sempre que for necessário fazer alguma alteração no sistema, devemos voltar ao modelo e fazer a inclusão, para que o modelo nunca fique diferente do sistema criado.

FONTE: Piva (2010, p. 164)

TÓPICO 2 | INTEGRAÇÃO DOS DIAGRAMAS – UMA VISÃO GERAL DO DESENVOLVIMENTO USANDO UML

121

Verifique a situação no Diagrama de Visão Geral, proposto abaixo.

FIGURA 56 – DIAGRAMA DE VISÃO GERAL

122


FONTE: Piva (2010)

123

Neste tópico você:

• Visualizou a interação entre todos os diagramas envolvidos em uma modelagem orientada a objetos.

RESUMO DO TÓPICO 2

124

AUTOATIVIDADE

1 Descreva os passos para a visualização da integração dos diagramas.

125

TÓPICO 3

ESTUDO DE CASO

UNIDADE 3

1 INTRODUÇÃO

Uma empresa é formada por um conjunto de processos inter-relacionados. Logo, o aumento da eficiência da empresa deve ser obtido em função da compreensão e melhoria destes processos. Um processo dispõe de inputs, outputs, tempo, espaço, ordenação, objetivos e valores que, interligados logicamente, irão resultar em uma estrutura para fornecer produtos ou serviços ao cliente. Quase toda a operação de uma empresa pode ser traduzida como um conjunto harmônico de processos e subprocessos que interagem para que os produtos e serviços sejam entregues com eficiência, qualidade e nos prazos desejados pelos clientes.

Todos os processos podem (e devem) ser melhorados ao longo do tempo para que os resultados sejam cada vez mais satisfatórios. Segundo Barbalho et al. (2002), um dos principais requisitos para o tratamento adequado de processos de negócio é sua efetiva compreensão, pois estando dispersos por várias áreas funcionais, é necessário que o gestor do processo conheça muito bem seus limites e abrangência.

Tal questão pode ser tratada com sucesso através da modelagem de processos, existindo até então diversas abordagens que se propõem a realizar tal intento. Faremos um estudo de caso aplicando a Linguagem de Modelagem Unificada (UML – em inglês Unified Modeling Language) para modelar um processo de negócio. A UML já é considerada um padrão para o modelamento de sistemas de informação, e caminha para especificações cada vez mais consistentes acerca do modelamento de processos de negócio.

FONTE: Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_tn_sto_069_496_11902.pdf>. Acesso em: nov. 2015.


126

FONTE: Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_tn_sto_069_496_11902.pdf>. Acesso em: 10 nov. 2015.

2 NECESSIDADE DE COMPREENDER OS PROCESSOS DA ORGANIZAÇÃO

O mapeamento de processos é útil para as empresas manterem-se competitivas através do contínuo aperfeiçoamento de seus processos, uma vez que proporciona uma metodologia estruturada para a busca da melhoria contínua. Segundo Hammer et al. (1999), a gestão por processos de negócio para as organizações aparece como alternativa vantajosa, desde que as ferramentas

TÓPICO 3 | ESTUDO DE CASO

127

para análise e mapeamento dos processos sejam de domínio do corpo técnico e gerencial da organização. O conhecimento dos processos de negócio evolui de forma contínua e altera consideravelmente a visão da organização, baseada em conceitos tradicionais que fragmentam as tarefas por níveis hierárquicos e por áreas funcionais.

Werneck et al. (2003) afirmam que a gestão por processos permite às empresas uma melhor visibilidade das atividades, o que propicia ações que promovam maior desempenho no fornecimento de seus produtos ou serviços, maior capacidade de adaptação a mudanças, uso otimizado de recursos e possibilidade de aprendizado. O mapeamento dos processos gera um modelo da realidade, permitindo analisar a estrutura e o comportamento da empresa, comparar, simular e propor melhorias destes processos.

Dessa forma, o mapeamento contribui para uma melhor compreensão das atividades da empresa e suas interações. Dentro deste contexto está a proposta deste trabalho, que vai utilizar o Diagrama de Atividades da UML para modelar e analisar um processo de negócio, usufruindo as vantagens deste diagrama na representação das atividades do processo. Além disso, o uso da UML permite aproximar a modelagem e a análise de processos com a Engenharia de Sistemas.

2.1 O MAPEAMENTO DE PROCESSOS

Barbalho (2002) afirma que um importante elemento de um modelo de processos de negócio é sua navegabilidade. Uma boa navegabilidade significa que é possível a um usuário do modelo caminhar entre as visões de uma maneira lógica, sem que seja necessário quebrar o raciocínio, mas ao contrário, construindo uma teia de relações que permita uma visão holística do processo modelado. Algumas técnicas de mapeamento de processo, como o fluxograma, apresentam-se consagradas na literatura, porém, novas técnicas de mapeamento estão sendo discutidas, dentro de suas limitações e alcances. A seguir apresenta-se uma breve descrição das técnicas mais utilizadas para mapeamento e análise de processos.


128

2.1.1 Fluxograma

O fluxograma é um gráfico que demonstra a sequência operacional do desenvolvimento de um processo, que caracteriza: o trabalho que está sendo realizado, o tempo necessário para sua realização, a distância percorrida pelos documentos, quem está realizando o trabalho e como ele flui entre os participantes deste processo.

O quadro a seguir mostra os principais símbolos utilizados pelos profissionais de Processamento de Dados na elaboração de fluxogramas de processo.

QUADRO 1 - NOTAÇÃO – SIMBOLOGIA BÁSICA

Terminal - símbolo utilizado como ponto para indicar o início e/ou fim do fluxo de um programa.

Seta de fluxo de dados - permite indicar o sentido do fluxo de dados. Serve exclusivamente para conectar os símbolos ou blocos existentes.

Processamento - símbolo ou bloco que se utiliza para indicar cálculos (algoritmos) a efetuar, atribuições de valores ou qualquer manipulação de dados que tenha um bloco específico para sua descrição.

Entrada de dados - utilizado para ler os dados necessários ao programa.

Decisão - indica a decisão que deve ser tomada, indicando a possibilidade de desvios para diversos outros pontos do fluxo, dependendo do resultado de comparação e de acordo com situações variáveis.

Conector - utilizado quando é preciso particionar o diagrama. Quando ocorrer mais de uma partição, é colocada uma letra ou número dentro do símbolo de conexão para identificar os pares de ligação.

O fluxograma originou-se a partir do aperfeiçoamento do diagrama de blocos e do fluxograma utilizado na área de processamento de dados. Como instrumento de múltiplas funções, o fluxograma, mediante sua representação gráfica, permite visualizar e compreender melhor os processos de trabalho em execução, as diversas fases operacionais, a interligação com outros processos e todos os documentos envolvidos.


129

2.1.2 SADT (Structured Analysis and Design Technic)

O SADT “nasceu pelas mãos” de Douglas T. Ross num projeto de desenvolvimento de uma linguagem estruturada para programação de máquinas-ferramenta, no fim da década de 60. Este formalismo trazia algumas características revolucionárias, como a decomposição funcional e o fato de ser baseado numa representação esquemática simples, que auxiliou sobremaneira a descrição e o desenvolvimento dos sistemas de software complexos que começavam a aparecer (VERNADAT, 1996). Estas características disseminaram a aplicação deste formalismo e também o seu desenvolvimento em direção a abordagens estruturadas completas destinadas a diferentes aplicações, principalmente para a análise de sistemas.

O SADT e o IDEF0 são apresentados juntos, pois têm origens e uma vida tão próximas que seus nomes até mesmo são fundidos na prática.

2.1.3 IDEF3

À medida que as técnicas de representação de processos foram evoluindo, técnicas mais sofisticadas foram sendo aplicadas em processos de serviços. Um bom exemplo é a aplicação do IDEF3. O IDEF3 é um dos integrantes da família de técnicas IDEF (Integrated ComputerAided Manufacturing), que foi desenvolvida pela Força Aérea dos Estados Unidos com o objetivo de descrever, especificar e modelar sistemas de manufatura (ALMEIDA et al., 2003).

De modo geral, o IDEF3 fornece um mecanismo coletando e documentando processos. Ele captura relações da precedência e de causalidade entre situações e eventos em um formulário natural aos peritos do domínio, fornecendo um método estruturado para expressar o conhecimento sobre como um sistema ou um processo atua na organização. Segundo Costa (2002), as descrições IDEF3 podem:

• Gravar os dados cruzando resultados das entrevistas fact-finding (fato-encontrado) em atividades da análise dos sistemas.

• Determinar o impacto do recurso da informação de uma organização nos cenários principais da operação de uma empresa.

• Documentar os procedimentos da decisão que afetam os estados e o ciclo de vida de dados compartilhados críticos, particularmente manufaturar, projetar, e dados da definição de produto da manutenção.

• Controlar a configuração dos dados e mudar a definição da política do controle.

• Fazer o sistema projetar a análise do trade-off (fim de negócio).• Fornecer a geração do modelo da simulação.


130

2.1.4 UML (Unified Modeling Language)

A UML está emergindo como a notação-padrão para modelagem, sendo assim é importante compreendê-la. Segundo Furlan (1998), a UML vai além de uma simples padronização em busca de uma notação unificada, uma vez que contém conceitos novos que não são encontrados em outros métodos orientados a objeto.

A UML é uma linguagem padrão para especificar, visualizar, documentar e construir artefatos de um sistema e pode ser utilizada com todos os processos ao longo do ciclo de desenvolvimento de software e através de diferentes tecnologias de implementação. Alguns autores, como Wilcox et al. (2003), defendem a utilização da UML, destacando as seguintes vantagens:

• Simplicidade nas notações.• Alta padronização encontrada nas aplicações publicadas.• Alta aplicabilidade nos processos reais.• Notação flexível às diversas situações.

Para aplicação neste trabalho foi escolhida a UML, pois, como é uma linguagem utilizada no desenvolvimento de software, seu uso se justifica no sentido de integrar a análise do processo e a concepção do sistema (software).

2.1.5 Diagrama de Atividades

O modo para descrever os vários aspectos de modelagem pela UML é através da notação definida pelos seus vários tipos de diagramas. Um diagrama é uma apresentação gráfica de uma coleção de elementos de um modelo, frequentemente mostrado como um gráfico conectado de arcos e vértices (FURLAN, 1998).

Os diagramas usados pela UML são: Diagrama de Casos de Uso, Diagrama de Classes, Diagrama de Objetos, Diagrama de Gráfico de Estados, Diagrama de Atividades, Diagrama de Sequências, Diagrama de Colaborações, Diagrama de Componentes e Diagrama de Implantação.

Esses diagramas permitem a modelagem de todas as fases de um projeto de software. Utilizaremos apenas o Diagrama de Atividades, que é um diagrama de estado especial onde a maioria dos estados é estado de ação e a maioria das transições é ativada por conclusão das ações nos estados precedentes, mostrando o fluxo de uma atividade para outra.

Este diagrama é importante quando se pretende descrever um comportamento paralelo, pois nem sempre os procedimentos se caracterizam por


131

uma sequência mecânica de passos. Um Diagrama de Atividades é essencialmente um fluxograma que dá ênfase à atividade que ocorre ao longo do tempo.

Um Diagrama de Atividades é composto por:

• Início: Representado por um círculo preenchido.• Estado de Atividade ou Atividade: Representado por um retângulo com

bordas arredondadas.• Transição: quando uma atividade termina, o fluxo de controle passa

imediatamente para a atividade seguinte. Representado por uma linha orientada.

• Desvio: Representado por um losango. Indica caminhos alternativos a tomar em um diagrama, mediante alguma expressão.

• Intercalação: Também representado por um losango, é utilizada para marcar o final de um comportamento condicional iniciado por um desvio, ou seja, tem múltiplas entradas e uma única saída.

• Separação: Representado por um traço horizontal, quando temos comportamento paralelo, ou seja, temos uma entrada e várias transições de saída que são executadas em paralelo.

• Junção: Representado por um traço horizontal, utilizamos para completar a separação, ou seja, quando temos um processamento paralelo, precisamos sincronizar.

• Raias: Representada por retângulos que englobam todos os objetos que estão ligados a um departamento. São usadas para indicar as entidades responsáveis pela execução das atividades, em geral estruturas organizacionais. Com o conjunto de elementos do Diagrama de Atividades é possível representar qualquer processo que tenha como base uma sequência de atividades inter-relacionadas.

2.1.6 Aplicação do Diagrama de Atividades da UML

Para o estudo de caso deste trabalho foi escolhida uma empresa que atua no mercado desde 2006. Os serviços desenvolvidos pela empresa são projetos e execução de pavimentação, passeios e reformas em escolas e praças. Por ser uma empresa criada há pouco mais de um ano, ela vem passando por uma série de adequações e melhorias contínuas em seus processos, ainda não tendo atingido um modelo considerado como “ideal”.

Assim surgiu a oportunidade de aplicar a UML em um dos processos da empresa, visando à identificação de pontos críticos e propondo melhorias de performance/qualidade, modelando o processo escolhido através do Diagrama de Atividades. O processo escolhido para análise neste trabalho foi a execução de pavimentos. Apresenta-se abaixo a descrição do procedimento para que seja dado início a este processo.


132

O diagrama correspondente é mostrado na figura adiante.

Primeiramente deve haver interesse por parte dos moradores da rua a ser beneficiada, visto que eles participam financeiramente da obra. Um destes moradores deve ir até à empresa e retirar o “termo de adesão” para colher as assinaturas dos vizinhos. Havendo interesse de, pelo menos, 70% dos moradores da referida rua, é aberto um protocolo de pavimentação. No Diagrama de Atividades mostrado na figura a seguir o processo inicia-se com a abertura deste protocolo (1).

Um protocolo também é aberto para solicitações de vereadores, sendo que neste caso não é exigido o termo de adesão, apenas o pedido é enviado ao diretor-presidente, para que seja analisado (2).

Este protocolo, seja pedido de clientes ou de vereadores, é enviado ao Departamento Comercial, para análise do referido trecho (3), e posteriormente repassado à Engenharia, para que verifique se o trecho em questão já não foi orçado anteriormente (4).

Assim, tem-se duas possibilidades: se o trecho já foi orçado este é enviado diretamente ao arquivo (5), e o processo é finalizado; caso o trecho não tenha sido orçado, o protocolo é enviado à Topografia para que seja realizado o levantamento e feito o anteprojeto da rua (6).

Isto feito, o protocolo retorna à Engenharia para que sejam feitos o orçamento e o projeto definitivo do trecho (7). Juntamente com o projeto e o orçamento, o protocolo é enviado ao Departamento Comercial para que seja feito o croqui com os dados da rua e dos respectivos moradores (8).

A partir deste momento, o mesmo departamento entra em contato com o vendedor da região em questão, para repassar-lhe a pasta da rua, com o croqui e o valor a ser pago pelos clientes para viabilização da obra (9). De posse disto, o vendedor deve visitar cada morador, e oferecer-lhe a pavimentação (10). Após as visitas, tem-se novamente duas situações: a rua pode ter atingido 70% de adesão, que é a exigência mínima para que seja executado o trecho, ou não. Caso ocorra a última opção, o processo é arquivado (11). Se a rua atingir os 70% de adesão, o vendedor solicita a documentação de cada morador e preenche a ficha cadastral (12).

De posse de todos os documentos, o vendedor envia estes dados ao Departamento Comercial para analisar toda a documentação da rua (13). Após esta análise, a documentação pode estar completa (14), ou os clientes podem ter impossibilidade de apresentar algum tipo de documento exigido, como comprovante de renda, por exemplo. Neste caso, o protocolo é enviado ao diretor-presidente para que ele avalie a documentação pendente (15).


133

Após a análise, a documentação pode ser reprovada (16), sendo o processo arquivado, ou aprovada (17). Se a documentação for aprovada, ou se ela já estivesse completa desde o início, o Departamento Comercial redige os contratos (18). Pode-se ter dois tipos de contratos, quando o cliente financia diretamente com a empresa (em até 30 vezes) (19), ou quando o financiamento é feito pelo Banco do Brasil (em até 48 vezes) (20).

Os clientes que optarem por financiar com o Banco do Brasil recebem um desconto de 15%, pois para a empresa o recebimento é à vista. Como o Departamento de Engenharia só insere o trecho no cronograma de obras quando a rua atinge 50% de recebimento, o trecho vendido é repassado ao Departamento Financeiro, para aguardar esta porcentagem de recebimento (21). Quando o financiamento acontece direto com a empresa, existe a consulta ao SPC (22). Após a consulta tem-se novamente duas situações: o cliente pode estar com a documentação regular ou pendente. Se a situação estiver regular (23), o processo é encaminhado à Recepção, para que sejam impressos os boletos (24).

Caso o cliente esteja com pendência no SPC, o Departamento Comercial entra em contato com o vendedor (25), que avisa o cliente sobre a pendência no SPC e verifica a possibilidade de regularizar a situação. Estes clientes podem regularizar a situação, dando andamento ao processo e gerando os boletos (26), ou não, continuando com a situação irregular (27). Neste caso, cabe à presidência verificar se, retirando este cliente inadimplente, a rua continua com 70% de adesão. Caso afirmativo, o processo segue, sendo repassado à Recepção para que sejam impressos os boletos (28).

Se retirarmos este cliente, e a rua ficar com adesão inferior a 70%, este protocolo é arquivado por falta de adesão (29). Com os boletos gerados, e os clientes efetuando os pagamentos mensais, a rua é repassada ao Departamento Financeiro (30) para que este realize o controle de recebimentos (21). Tão logo a rua atinja os 50% de recebimento (31), esta é enviada ao Departamento de Engenharia para que seja inserida no cronograma de obras (32). Para facilitar o deslocamento dos maquinários, o cronograma de obras é dividido por regiões da cidade, chamadas lotes.

Quando é iniciado um determinado lote, todas as ruas vendidas desta região que estejam 50% pagas são pavimentadas. Buscando aumentar a produtividade, pode-se executar a obra (33) ou terceirizar a obra (34). No último caso, a empresa passa de executora a fiscalizadora, porém, o procedimento é realizado da mesma forma. Quando a obra é finalizada, o protocolo é arquivado (35).


134

RECEPÇÃO COMERCIAL ENGENHARIA TOPOGRAFIA PRESIDÊNCIA FINANCEIRO ARQUIVOVENDAS

AbrirProtocolo

Analisarpedido

Analisaro trecho

Verificar ostrechos jáusados

Encaminharpara

levantamentotopográfico

Fazer croquicom dados

da rua erespectivosmoradores

Relizarlevanta-mento e

anteprojeto

Conectarvendedor da

região

Protocoloarquivado

(1)

(1)

(3)(4)

Solic.deCliente

Solicitação de Vereadores (2)

Trecho nãoorçado (6)

(7)(8)

(9)

(10)

Trecho já orçado (5)

Orçar eprojetar o

trecho

Visitarmoradores

Protocoloarquivado

Solicitara doc. de

cadamorador

Preenchera ficha

cadastral

Analisar adocumentação

Analisar adocumentação

pendente

não atingiu70%

de adesão(11)

Rua c/no mín.70% deadesão

(12)

(13)

Doc.

Impossibilidadede

apresentar um documento(15)

Protocoloarquivado


135

Redigir contratos

Executara obra

Fazerboletos

Ok

(14)

(18) Cont.

Doc.

Doc.Apro-vada

reprovada

(17)

(16)

Cont.(18)

(21)

Presidente

Regular

(25)

(23)

(19)

(22)

(20)

(27)

(26)

(28)(29)

Sit.

Sim

Não

Sit.

irreg.

Reg.

(24)

(30)

(32)(3

(2

Financ.c/BB

Financ.c/ a

Empresa

Empresarecebea vista

ConsultaSPC

Avisarclientesobre

pendênciano SPC

Verificar apossibilidade de

regularizar asituação

Verificar seretirando estecliente a ruacontinua com

70% de adesão

Protocoloarquivado

Aguardar50% de

recebimento

Rua atingida50% de

recebimentoInserir o

trecho nocronograma

de obras


136

Terceirizara obra

Protocoloarquivado

(33)(34)

(35)

Figura 1 - Diagrama de Atividades

2.1.7 Avaliação da Aplicação do Diagrama de Atividades

Após o mapeamento verificou-se que o Diagrama de Atividades da UML permitiu a visualização do processo, possibilitando uma representação padronizada das informações com um nível de detalhamento adequado. A aplicação do Diagrama de Atividades no processo leva a organização a reconhecer os pontos fracos ou gargalos da empresa. Neste estudo de caso, após o mapeamento do processo, foram intensificadas as seguintes possibilidades de melhorias:

• Após ser aberto um protocolo, o Departamento Comercial o envia à Engenharia, para que seja verificado se este trecho de rua já foi orçado ou não (4), sendo que isto poderia ser feito pelos funcionários da recepção antes mesmo de um protocolo ser aberto. Muitas vezes são abertos vários protocolos para um mesmo trecho de rua, e isto só é verificado quando o processo passa pelo Departamento de Engenharia.

• Se a Recepção procedesse conforme descrito acima, esta poderia repassar o protocolo diretamente à Topografia, eliminando diversas etapas e diminuindo o prazo entre a solicitação de clientes interessados e a visita de um vendedor, já com o orçamento da rua.

• Quando o cliente financia direto com a empresa (22), é feita a consulta ao SPC e, em diversos casos, os clientes estão com a situação pendente (25). Esta consulta poderia ser efetuada diretamente pelo vendedor, antes de repassar a documentação e as fichas cadastrais ao Departamento Comercial (13).

• Após a obra concluída é importante que um representante da empresa retorne ao local para obter o feedback do serviço executado e também para verificar se a obra está em perfeitas condições de uso e limpeza. É necessário que se visite cada morador para que se possa obter um indicador de clientes satisfeitos/insatisfeitos e propor uma meta a ser alcançada, preocupando-se sempre em atingir resultados melhores. A principal vantagem da utilização de um diagrama associado a UML é que após a análise e identificação de possíveis melhorias em um processo, o modelo poderá ser aproveitado integralmente para iniciar o desenvolvimento do sistema de informações que dará suporte ao processo.


137

2.1.8 Conclusões

Observou-se que o mapeamento do processo através do Diagrama de Atividades trouxe resultados importantes, como o entendimento e a visualização global do processo por toda a organização, apresentando as informações de forma clara e padronizada e mostrando o fluxo de uma atividade para outra.

O Diagrama de Atividades também possibilitou encontrar os pontos críticos e gargalos da empresa, e assim, propor sugestões de melhorias, que certamente levarão a um aumento da eficiência e da qualidade do processo como um todo, possibilitando o aumento de sua competitividade no mercado. Conclui-se, tendo como base este estudo de caso, que o Diagrama de Atividades da UML atendeu ao objetivo deste trabalho, permitindo o mapeamento de um processo de negócio de maneira satisfatória, contribuindo para uma melhor compreensão das atividades da empresa e suas interações, podendo ser utilizado para modelagem de processos e não apenas para modelagem de softwares.

FONTE: Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_tn_sto_069_496_11902.pdf>. Acesso em: nov. 2015.


138


O uso de software de apoio à modelagem é muito importante, por dois motivos: primeiro porque os modelos começarão a ficar tão longos que a folha de papel ficará pequena, segundo porque é uma ótima maneira de checar as associações entre os modelos. [5]. O principal objetivo da tecnologia CASE é separar o projeto da implementação do código. Existem várias ferramentas de modelagem, algumas suportando a UML, porém muitas apoiam um método particular que em si atende a um tipo de projeto. É essencial avaliar os benefícios das ferramentas e suas limitações, evitando problemas posteriores no processo de desenvolvimento.

Com um grande número existente de ferramentas CASE, com vários recursos característicos que proporcionam, é necessário conhecer quais delas apoiam melhor a UML. Entretanto, para que isto seja possível é preciso fazer uma verificação das ferramentas disponíveis e avaliar suas principais características.

Atualmente existem várias ferramentas de apoio à UML. O site Objects by Design [7] apresenta, aproximadamente, 115 ferramentas com informações sobre seus fabricantes, versões, datas, plataformas e preços (nem sempre disponível). O

139

presente artigo apresenta um modelo para avaliação de ferramentas de suporte à UML, baseado em requisitos funcionais, não funcionais, bem como em normas de qualidade. Inicialmente apresenta-se as categorias definidas no modelo de avaliação, bem como os critérios que formam cada categoria. Apresenta-se a seguir o estudo de caso que foi definido e realizado a fim de validar o modelo proposto. Posteriormente, são apresentados os principais resultados obtidos com o estudo de caso, algumas observações complementares constatadas na avaliação e, finalmente, a conclusão.

2. O Modelo Proposto

O site anteriormente mencionado apresenta, também, uma lista comentada de itens que devem ser considerados nas ferramentas. Porém, a lista não aponta quais tipos de respostas devem ser buscados e nem uma organização precisa dos itens (classificação), o que dificulta, em parte, sua aplicação. Além disso, os itens não são relacionados com normas de qualidade. Sendo assim, a finalidade do modelo proposto é estabelecer um conjunto de critérios, baseados em normas de qualidade e classificados em requisitos funcionais e não funcionais, que permitam a avaliação de ferramentas de apoio à UML.

Após a avaliação, segundo os critérios propostos, as informações obtidas poderão auxiliar o futuro usuário na escolha da ferramenta de apoio à UML mais adequada às suas necessidades. Os critérios definidos no modelo permitem especificar como as ferramentas trabalham, se realmente executam o que seu fabricante anuncia e se atendem aos requisitos dos usuários com qualidade. Porém, não é objetivo do modelo indicar qual ferramenta é a melhor. A opção será feita pelo usuário a partir dos resultados obtidos.

Para uma melhor definição dos critérios, investigou-se algumas normas de qualidade existentes. As normas de qualidade investigadas foram: ISO/IEC 9126 - Engenharia de Software - Qualidade de produto de software, ISO/IEC 14598 - Tecnologia de informação – Guias para avaliação de produto de software, NBR ISO/IEC 12119 - Tecnologia de informação - Pacotes de software - Testes e requisitos de qualidade [4] e ISO/IEC 14102 - Tecnologia de informação – Orientação para avaliação e seleção de ferramentas CASE. A lista de critérios para avaliação das ferramentas foi criada para direcionar a avaliação. Os 57 critérios foram divididos em funcionais e não funcionais e apresentam duas formas de resposta, como mostra a Tabela 1.

Para uma melhor organização dos critérios, os mesmos foram classificados em categorias que servem para agrupar os critérios que possuem características semelhantes. Apresenta-se, a seguir, as oito categorias de critérios que foram criadas, bem como os objetivos principais de cada uma delas:

• Baseados na norma ISO/IEC 9126: verificar nas ferramentas a existência de características relacionadas a esta norma.

140

• Baseados em características de hardware e software: verificar em quais plataformas de hardware e software as ferramentas podem ser utilizadas.

• Baseados no repositório de dados: verificar quais são as funções do repositório nas ferramentas.

• Baseados na documentação: verificar que tipos de documentação acompanham as ferramentas e se as mesmas auxiliam os desenvolvedores no uso das ferramentas.

• Baseados no uso da ferramenta com relação ao computador utilizado: verificar qual o desempenho das ferramentas com relação ao computador utilizado para avaliação.

• Baseados na UML: verificar quais funções executadas pelas ferramentas correspondem com as características da UML.

• Baseados no fornecedor: possibilitar informações detalhadas sobre o fornecedor, produtos e suporte aos mesmos.

• Baseados nas necessidades identificadas com a utilização das ferramentas: verificar se as ferramentas atendem às necessidades dos usuários.

Tabela 1 - Tipos de Resposta

Critério Tipo de resposta CódigoÉ possível gerar código fonte a a partir da modelagem?

Sim/Não/Em parte, justificando se necessário. 1

Quais os bancos de dados apoiados pela ferramenta? Resposta descritiva 2

Nas próximas seções serão apresentados os critérios de cada categoria, bem como a motivação da criação de cada uma das categorias. Nas tabelas, a coluna “Resp” refere-se ao tipo de resposta do critério, conforme Tabela 1, e a coluna “Req” (Requisito) corresponde a F (Funcional) ou NF (Não Funcional).

2.1 Critérios baseados na norma ISO/IEC 9126

Os critérios desta categoria foram criados com base na norma ISO/IEC 9126. O objetivo é descobrir como as ferramentas atendem algumas características desta norma. Foram consideradas as características manutenibilidade (subcaracterísticas modificabilidade e analisabilidade), confiabilidade (subcaracterística maturidade), funcionalidade (subcaracterística interoperabilidade) e apreensibilidade. Nesta categoria foram criados 22 critérios, sendo que a Tabela 2 apresenta alguns exemplos.

141

Tabela 2 - Critérios baseados na norma ISO/IEC 9126

Critério Objetivo Resp Req

É possível incluir, excluir, mover, agrupar, desagrupar e redimensionar objetos?

Avalia a possibilidade de manipulação dos objetos na ferramenta depois de criados. O objetivo é verificar se após os elementos serem criados, os mesmos podem ser modificados.

1 F

Possui opções para análise dos diagramas?

Verificar se a ferramenta auxilia o desenvolvedor na depuração da modelagem, analisando todos os elementos criados.

1 F

É possível gerar código, fonte a partir da modelagem criada?

Verificar se o usuário poderá gerar código para a aplicação que está sendo desenvolvida.

1 F

É possível fazer engenharia reversa de dados? Verificar se a ferramenta possui este recurso. 1 F

É possível importar e exportar dados?

Verificar quais ferramentas importam/exportam arquivos do projeto que está sendo criado. 1 NF

Na ferramenta é possível valer-se de informações de outras ferramentas?

Avaliar se é possível utilizar subsídios de outras ferramentas. 1 NF

Os arquivos criados na ferramenta são portáveis para a mesma ferramenta em outra plataforma?

Avaliar se os arqeuivos criados na ferramenta podem ser utilizados nas versões da ferramenta criadas para outras platafromas.

1 NF

A ferramenta possui restrição quanto ao número de objetos criados pela mesma na modelagem?

Avaliar se a ferramenta possui alguma restrição quanto a criação de elementos na ferramenta.

1 NF

Existe maneira de prevenir falhas originadas por hardware ou software?

Verificar se a ferramenta possui recuperação de dados por meio de defeitos de hardware e/ou software

1 NF

A organização gráfica dos elementos visuais promove a compreensão do usuário na utilização da ferramenta?

Avaliar se a ferramenta é fácil de ser manipulada, verificando se o usuário terá facilidade para utilização da ferramenta a partir da visualização dos elementos.

1 NF

2.2 Critérios baseados na UML

Esta categoria é composta de quatro critérios que permitem avaliar a relação da ferramenta com características especiais da UML, como possibilidade de definição de herança múltipla, possibilidade de criação de todos os diagramas propostos pela linguagem e possibilidade de armazenar tarefas intermediárias dos casos de uso. A Tabela 3 apresenta os critérios definidos para esta categoria.

142

Tabela 3 - Critérios baseados na UML

Critério Objetivo Resp ReqPermite definir tarefas intermediárias em casos de uso?

Verificar se é possível documentar tarefas intermediárias dos casos de uso. 1 F

Permite definição de herança múltipla?

Verificar se a ferramenta possui esta opção no diagrama de classes. 1 F

Permite a criação de todos os diagramas propostos pela UML?

Verificar se é possível criar todos os diagramas da UML. 1 F

Qual é a versão da UML suportada pela ferramenta?

Informar ao usuário qual é a versão da UML suportada pela ferramenta. 2 NF

2.3 Critérios baseados no fornecedor

Com os critérios desta categoria é possível obter-se informações mais detalhadas sobre os fornecedores das ferramentas, como tempo de existência, forma de comercialização dos produtos, suporte oferecido etc. Foram definidos 11 critérios e todos correspondem a requisitos não funcionais. A Tabela 4 apresenta exemplos de critérios definidos para esta categoria.

Tabela 4 - Critérios baseados no fornecedor

Critério Objetivo RespHá quanto tempo o fornecedor está no mercado?

Informar há quanto tempo o fornecedor está atuando no mercado. 2

O fornecedor comercializa outros produtos?

Verificar se existem outros produtos desenvolvidos pelo fornecedor. 2

Há quanto tempo a ferramenta está disponível?

Verificar há quanto tempo a ferramenta está disponível para utilização. 2

Como é possível adquirir a ferramenta?

Verificar quais são as possibilidades de aquisição da ferramenta. 2

Como é feito o suporte aos clientes?

Verificar como é realizado o atendimento ao usuário 2

O produto possui alguma certificação de qualidade?

Verificar se a ferramenta possui alguma certificação de qualidade ou se existe alguma preocupação por parte do fabricante quanto a isto.

1

143

Tabela 5 - Critérios baseados nas necessidades identificadas com a utilização da ferramenta

2.4 Critérios baseados nas necessidades identificadas com a utilização da ferramenta

A partir dos seis critérios definidos nesta categoria é possível verificar se as ferramentas atendem às necessidades dos usuários na utilização das mesmas. A Tabela 5 apresenta exemplos de critérios definidos para esta categoria.

Critério Objetivo Resp ReqÉ possível gerar histórico das ações executadas?

Avaliar se disponibiliza registros do que é criado. 1 F

É possível abortar/desfazer ações executadas?

Avaliar se existe controle para determinadas ações, verificando se é possível desfazer ou abortar ações facilitando a criação dos modelos.

1 F

Existe alguma forma de controle e gerencimaneto de usuários?

Avaliar se existe controle e gerenciamento de usuários. 1 F

Quais são os conhecimentos mínimos para usar?

Identificar e informar quais devem ser os conhecimentos básicos de utilização. 2 NF

2.5 Critérios baseados em características de hardware e software

A partir dos critérios desta categoria é possível verificar as necessidades de hardware e software das ferramentas. Foram definidos cinco critérios nesta categoria e todos correspondem a requisitos não funcionais. Alguns exemplos são:

• É possível executar a ferramenta em quais sistemas operacionais? O objetivo deste critério é identificar para quais sistemas operacionais as ferramentas estão disponíveis. A resposta para este critério é descritiva (tipo 2), ou seja, uma lista de sistemas operacionais.

• Quais são os requisitos mínimos aconselhados pelo fornecedor para a utilização da ferramenta? Busca-se verificar quais os requisitos (memória, espaço em disco, processador, etc.) mínimos para a utilização das ferramentas. A resposta informa ao usuário qual deve ser a capacidade mínima do seu computador para que ele possa utilizar a ferramenta satisfatoriamente. A resposta para este critério é descritiva (tipo 2), ou seja, a configuração mínima sugerida pelo fabricante.

• É preciso uma base de dados específica para a ferramenta? Com este critério é possível investigar se as ferramentas necessitam de alguma base de dados para a criação dos diagramas. A resposta para este critério é do tipo 1.

2.6 Critérios baseados no repositório de dados

Nesta categoria buscou-se informações que permitissem avaliar as funções dos repositórios de dados das ferramentas. Para atingir este objetivo foram criados três critérios:

144

• Existe repositório? O objetivo deste critério é avaliar de que forma a ferramenta armazena os dados.

• Através do repositório é possível criar informações (classes, atributos, ligações)? Com este critério busca-se avaliar se os repositórios das ferramentas permitem a criação dos elementos dos diagramas a partir das informações salvas.

• É possível recuperar os dados do repositório? Busca-se informações para avaliar se os repositórios das ferramentas permitem a recuperação dos elementos dos diagramas a partir das informações salvas. Os critérios desta categoria correspondem a requisitos funcionais e possuem tipo de resposta 1.

2.7 Critérios baseados na documentação

Os critérios desta categoria demonstram a relação das ferramentas com a respectiva documentação. O objetivo é verificar se existe uma preocupação quanto à documentação e como a mesma é disponibilizada. Foram criados quatro critérios nesta categoria, todos correspondem a requisitos não funcionais e possuem resposta do tipo 1. A seguir são apresentados alguns exemplos de critérios desta categoria:

• Existe help, manuais e documentação que auxilie o usuário a esclarecer dúvidas? A partir da resposta a este critério é possível verificar a existência de documentação, de que tipo é a mesma e se realmente auxilia o usuário na utilização da ferramenta.

• Existe documentação que esclarece dúvidas quando à instalação? O objetivo é verificar se existe alguma documentação que auxilie a instalação da ferramenta.

• É possível configurar a forma como a documentação será gerada? Com este critério é possível verificar se o usuário poderá alterar a documentação gerada pela ferramenta de acordo com suas necessidades.

2.8 Critérios baseados na utilização da ferramenta com relação ao computador utilizado para avaliação

Nesta categoria busca-se informações que permitam avaliar as ferramentas com relação ao computador utilizado para avaliação das mesmas. Para atingir este objetivo foram criados dois critérios:

• Possui tempo de resposta apropriado? A partir da resposta a este critério pretende-se detectar como foi a resposta aos processos feitos na ferramenta.

• Qual o desempenho no computador utilizado? A intenção é indicar a viabilidade da utilização, orientando o usuário se poderá utilizá-la com a tecnologia que possui ou deverá utilizar mais recursos. Os critérios desta categoria correspondem a requisitos não funcionais e possuem resposta descritiva (tipo 2).

145

3. Aplicação do modelo

A fim de validar o modelo proposto, foi definido e elaborado um estudo de caso. Escolheu-se algumas ferramentas e elaborou-se os diagramas da UML com base em um Controle de Simpósio. Inicialmente foram identificados os atores e, logo após, realizou-se um levantamento das responsabilidades de cada um. As responsabilidades foram descritas como pequenas tarefas. A análise destas tarefas intermediárias possibilitou a identificação de prováveis casos de uso que serviram de base para a construção do diagrama correspondente. Em seguida, tornou-se possível a identificação das classes, bem como suas características e relacionamentos, dando origem ao Diagrama de Classes.

A partir da descrição das tarefas intermediárias de cada diagrama de caso de uso foram desenvolvidos os diagramas de sequência. A seguir, com base na classe Participante, criou-se o Diagrama de Estados e o Diagrama de Atividades baseou-se na classe Cancelamento. A Figura 1 apresenta uma parte do Diagrama de Classes construído.

Todos os diagramas elaborados encontram-se em [2]. As ferramentas escolhidas para este estudo foram a Rational Rose C++ Demo2 da IBM/Rational, PowerDesigner 9.03 da Sybase, Together ControlCenter 6.14 da Borland, AllFusion Component Modeler 4.15 da CA (Computer Associates), Enterprise Architect 3.516 da Sparx Systems, Poseidon for UML Community Edition 1.67 e ArgoUML 0.148. A Rational Rose foi escolhida por ser desenvolvida pela mesma empresa da UML; a PowerDesigner 9.0 por ser uma ferramenta de modelagem muito utilizada no meio acadêmico em geral; a Poseidon e a ArgoUml por serem ferramentas de código aberto; a Together ControlCenter, a AllFusion Modeler e a Enterprise Architect por serem ferramentas encontradas nas referências utilizadas.

Além disso, foi possível encontrar cópias de demonstração de todas as ferramentas acima citadas. A avaliação das ferramentas foi realizada através da aplicação do estudo de caso nas mesmas e consulta a informações disponibilizadas pelo seu fornecedor por meio da documentação de cada uma delas.

3.1 Resumo dos Resultados

Durante a avaliação foi possível criar a modelagem de acordo com as exigências da UML. Constatou-se que cada ferramenta possui padrões e características diferentes. Os principais resultados constatados com a avaliação são mostrados na Tabela 6.

146

3.2 Observações finais sobre a avaliação

Através da avaliação verificou-se que cada ferramenta possui características e padrões diferentes que devem ser ressaltados. Identificou-se que em todas as ferramentas é possível criar a modelagem conforme a UML, porém, dependendo da ferramenta isto pode ser feito com maior ou menor dificuldade. Todas as ferramentas estudadas oferecem várias formas de documentar os projetos, reforçando uma das principais características da UML, que é de ser uma linguagem de documentação. Além dos diagramas da UML, constatou-se que algumas ferramentas, como a Together ControlCenter, Enterprise Architect e Allfusion Component Modeler, oferecem modelagem de negócios, e a PowerDesigner possibilita modelagem física e conceitual. Observou-se, com exceção da versão da Rational Rose estudada, que todas as ferramentas preocupam-se com a portabilidade dos seus modelos, mesmo as que não possuem versões para outros sistemas operacionais, pois elas oferecem exportação de seus modelos em XML. A maioria das ferramentas é bem construída graficamente, a Poseidon e a Together ControlCenter possuem ícones com os desenhos na forma dos diagramas correspondentes, facilitando a compreensão e agilizando a construção dos mesmos. Além disto, com exceção da AllFusion Component Modeler, todos os diagramas podem ser visualizados facilmente através do browser, pois são agrupados conforme o tipo de diagrama de acordo com a UML. As empresas que não possuem recursos financeiros ou não desejam gastar para adquirir uma ferramenta podem utilizar a Argouml e a Poseidon, porque são de código aberto e distribuídas gratuitamente.4. Conclusões

A UML é uma tendência entre desenvolvedores de aplicações baseadas em modelos orientados a objetos, entretanto, há uma grande dificuldade de encontrar experiências práticas e exemplos mais realistas na literatura, tornando lento o processo de inserção desta metodologia no mercado de trabalho. Existem grandes esforços para mudar este panorama. A prova disto é o investimento do OMG em melhorias na UML lançando constantemente novas versões. Atualmente, existem várias ferramentas de apoio à UML. A fim de facilitar a avaliação destas ferramentas, definiu-se um modelo composto por um conjunto de critérios baseados em requisitos funcionais, não funcionais e normas de qualidade. O objetivo do modelo é auxiliar o usuário para que ele obtenha informações sobre cada ferramenta a fim de que, a partir destas informações, possa escolher a que melhor atenda às suas necessidades ou, valendo-se dos dados do estudo, criar uma nova avaliação. Não é objetivo deste modelo indicar qual a melhor ferramenta, bem como abordar custos de aquisição e manutenção. Sugere-se que após a realização da avaliação, o usuário estabeleça prioridades aos critérios de acordo com suas necessidades. Para os critérios podem ser atribuídas faixas de valores, por exemplo 0 a 5, que demonstrará em que grau a ferramenta atende àquele critério. Assim, a ferramenta que melhor atender as necessidades é a que

147

totalizar mais pontos. Cabe enfatizar que, na seleção de ferramentas, é importante considerar tanto os requisitos funcionais como os não funcionais. Por esta razão, na elaboração dos critérios do modelo proposto teve-se a preocupação em fazer esta distinção.

O crescente aumento de novas ferramentas disponíveis, incluindo algumas de código aberto e uso livre, e a constante atualização das mesmas para versões superiores, motivam a complementação deste trabalho abrangendo mais características das ferramentas avaliadas, com a elaboração de novos critérios. Também é possível estender a avaliação realizada para um maior número de ferramentas.

148

Vagas codvaga: integrar qtdisp: integer qtvaga: integer Evento: string Periodo: string

Estudante matricula: string nivel: string

Outro Atividade: string

Categoria codcat: integer descat: string valor: float

Professor area: string codinst: instituição

Profissional da Area codemp: string codcargo: string

Cidade codcid: string nomecid: string UF: string

Cancelamento codpant: Participante dtcancel: string

1

1

Participante

ccodpartnome: string

endereco: stringdrinscircao: string

dtpgto: stringCep: stringFone: string

codcid: Cidadestatus: string

codcat: Categoria

(from Use Case View

0...*0...*

Tabela 5 - Critérios baseados nas necessidades identificadas com a utilização da ferramenta

Item Resultado

Importação e Exportação de Arquivos

Com exceção da Rational, todas exportam dados em XML, A PowerDesigner importa os modelos criados na Rational, mas o diagrama de classes fica com os objetos e ligações confusos na ferramenta, após a importação. A Poseidon abre modelos criados na Argouml e vice-versa.

Portabilidade

A Enterprise Architect e Allfasion possuem versões apenas para o WIndows, as demias (exceto a PowerDesigner que não identificou-se) contém versões para outros sistemas operacionais. A Poseidon e a Argouml inpedem do mesmo.

Harware e Software Necessários

128 MB de RAM recomendada pelo fornecedor é insuficiente para a utilização da Poseidon e da Argouml. Para a Together é recomendado no mínimo 512MB. As ferramentas Together e Allfusion requerem grande espaço em disco (a partir de 100 MB); par Enterprise Architect Argouml e Rational Rose é necessário até 15 MB e par Poseidon e PowerDesigner não foi possível identificar, porém o tamanho do arquivo de instalação das mesmas e superior a 60MB. O drive de CD só é necessário para instalação das ferramentas. Recomenda-se uma placa de vídeo com resolução mínima de 800x600, exceto para a Together pois o fornecedor recomenda 1024x768.

149

Reposi´torio de Dados

Somente a Allfusion necessita de instalação de uma base de dados específica (MS SQL Sever). A PoqerDesigner, Enterprise Architect e AllFusion Component Modeler possuem repositórios de dados que permitem controlar uusários ou grupos de usuários, atribuindo-lhes permissões para os projetos; a Together também contém este controle, porém como acontece com as demais, o repositório de dados é utilizado apenas como um browser para visualização dos elementos dos diagramas. Com exceção da Poseidon e da Rational Rose (que não foi possível identificar), todas têm suporte a algum banco de dados.

Interface Com exceção da AllFusion Component Modeler, todas são muito bem organizadas graficamente.

Documentação Todas são acompanhadas de documentação, sendo também disponibilizadas na página correspondente.

Conhecimentos Prévios COm execção da AllFusion Component Modeler, não houve dificuldades na manipulação das ferramentas.

FONTE: Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_tn_sto_069_496_11902.pdf>. Acesso em: 10 nov. 2015.

150

Neste tópico você:

• Observou que o mapeamento do processo através do Diagrama de Atividades trouxe resultados importantes, como o entendimento e a visualização global do processo por toda a organização, apresentando as informações de forma clara e padronizada e mostrando o fluxo de uma atividade para outra.

• O Diagrama de Atividades também possibilitou encontrar os pontos críticos e gargalos da empresa e, assim, propor sugestões de melhorias, que certamente levarão a um aumento da eficiência e da qualidade do processo como um todo, possibilitando o aumento de sua competitividade no mercado.

RESUMO DO TÓPICO 3

151

AUTOATIVIDADE

1 Descreva os passos do Diagrama de Atividades proposto no Estudo de Caso abordado acima.

153

REFERÊNCIAS

ANDRADE, C. A. V. Metodologia de Análise de Sistemas. 8. Módulo. ESAB – Escola Superior Aberta do Brasil: Vila Velha, 2007.

BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, 2007.

BIGERSTAFF, T; RICHTER C. Re-usability Framework, Assessment and Directions. Tutorial: Software Reuse - Emerging Technology. IEEE Computer Society, EH0278-2, p. 3-11. 1989.

BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos com UML 2. 2. ed. Rio de Janeiro: Elsevier, 2006.

BOOCH, G. Object-Oriented Analysis and Design with Applications. USA: Redwood City, Benjamin, 2006.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Rio de Janeiro: Elsevier, 2005.

BROOKS, F. P. No Silver Bullet: Essence and Accidents of Software Engineering. Computer, New York, vol. 20, n.4, p. 10-19, Apr. 1987.

FRANK, A U., EGENHOFER, M. J. Computer Cartography For GIS: An Object-Oriented View On The Display Transformation. Computers & Geosciences, Oxford, v. 18, n. 8, p. 975-987, 1992.

GRAHAM, I. Object Oriented Methods. Addison-Wesley: Wokingham, England, 1994.

GUEDES, G. T. A. Uml 2: Uma Abordagem Prática. 2. ed. São Paulo: Novatec, 2011.

______. Uml 2: Guia Prático. São Paulo: Novatec, 2007.

HAMILTON, K.; MILES, R. Learning UML 2.0. O’Reilly, 2006.

HERRING, J. A Data Model For An Object-Oriented Geographic Information System. Computers & Geosciences, Oxford, v. 18, n. 4, p. 443-452, 1992.

LARMAN, C. Utilizando UML e padrões. 3. ed. Porto Alegre: Bookman, 2007.

154

MANHANI, D. M. da S.; SCHIMIGUEL, J. Ferramentas case para modelagem de banco de dados. Codificando .net e-magazine. Rio de Janeiro, ano 4, v. 14, 1º fev. 2010.

MARTINS, D. M. S. et al. Projeto de software com astah*. Engenharia de software magazine. Rio de Janeiro, ano 3, v. 30, 11 mar. 2010.

MELO, A. C. Desenvolvendo Aplicações com UML 2.2. 3. ed. Rio de Janeiro: Brasport, 2011.

PIVA, G. D. Análise e Gerenciamento de Dados. Manual de Informática Centro Paula Souza, v. 3, São Paulo, 2010.

PRIETO R.; FREEMAN, P. Classifying software for reusability. IEEE Software, [S. l.], v. l4, n.1, p. 6-16, 1987.

RUMABAUGH, J. E. et al. Object-Oriented Modeling and Design. Englewood Cliffs, New Jersey: Prentice Hall, 1991.

SILVA, R. P. e. UML 2 em Modelagem Orientada a Objetos. Florianópolis: Visual Books, 2007.

SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Addison Wesley, 2011.

SOMMERVILLE, I. Software Engineering. Wokingham, England: Addison-Wesley, 1989.

TACLA, C. A. ANÁLISE E PROJETO OO E UML 2.0. Apostila: Departamento Acadêmico de Informática. Universidade Federal Tecnológica do Paraná, 2010.

TONSIG, S. L. Engenharia de software: Análise e Projeto de Sistemas. 2. ed. Rio de Janeiro: Ciência Moderna, 2008.

VIDEIRA, C. A. E. UML, metodologias e ferramentas case. 2. ed. Lisboa: Centro Atlântico, 2008.

ZHANG, H. BJORNERUD, M. A Macintosh Application Program for Simulating Shear-Sense Indicators Using Object-Oriented Programming. Computers & Geosciences, Oxford, v. 21, n. 3, p. 365-375, 1995.

155

ANOTAÇÕES

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

156

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

análise orientada a objetos ii - uniasselvi

Documents