FACULDADE DO LITORAL SUL PAULISTA – FALS
MARCOS ANTONIO FERIAN FILHO
SISTEMA DE GERENCIAMENTO DE VENDA
UML
PRAIA GRANDE
2010
MARCOS ANTONIO FERIAN FILHO
SISTEMA DE GERENCIAMENTO DE VENDA
UML
Projeto de Matéria de Trabalho de conclusão
de curso, Faculdade do Litoral Sul Paulista,
sob orientação do Prof. Paulo R. T. Cândido.
PRAIA GRANDE
2010
MARCOS ANTONIO FERIAN FILHO
SISTEMA DE GERENCIAMENTO DE VENDA
UML
Projeto de Matéria de Trabalho de conclusão
de curso, Faculdade do Litoral Sul Paulista,
sob orientação do Prof. Paulo R. T. Cândido.
AVALIAÇÃO:
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
NOTA: ____(________)
PRAIA GRANDE
2010
RESUMO
É de extrema importância utilizar uma metodologia de desenvolvimento de
sistema para obtermos, desde os primeiros passos, até a etapa final de conclusão
do projeto de software. Citamos a UML por ser a unificação das três mais
conceituadas linguagens de modelagem de sistemas orientadas a objetos (Booch de
Grady, OOSE de Jacobson e o OMT de Rumbaugh). Este trabalho mostra a
utilização da UML no sistema para que se possa criar uma metodologia de
desenvolvimento do sistema que englobe todas as fases do projeto, desde os
eventos iniciais, passando pelo levantamento de Requisitos, Análise, Projeto,
Programação e Testes.
PALAVRAS
CHAVES:
metodologia,
desenvolvimento,
UML,
Programação.
5
ABSTRACT
It is extremely important to use a system development methodology to
obtain, from the early stage until the final stage of completing the software project.
We quote the UML to be the unification of the three most prestigious modeling
languages for object-oriented systems (Grady Booch, OMT and Jacobson's OOSE of
Rumbaugh). This work shows the use of UML in the system so you can create a
system development methodology that encompasses all phases of a project from the
initial events, going from Olympic Requirements, Analysis, Design, Programming and
Testing.
KEY WORDS: methodology, development, UML, Programming
6
SUMÁRIO
1 INTRODUÇÃO ...................................... Erro! Indicador não definido.
1.1
APRESENTAÇÃO ...............................................................................................................8
1.2 OBJETIVOS GERAIS E ESPECÍFICOS ................................................................................9
1.3
JUSTIFICATIVA ...............................................................................................................10
1.4
ABRANGÊNCIA ................................................................................................................10
1.5
METODOLOGIA ...............................................................................................................10
1.6
ESTRUTURA ......................................................................................................................11
2 ANÁLISE E PROJETOS ORIENTADOS A OBJETOS ...................... 12
2.1 CONCEITOS E HISTÓRIA .....................................................................................................12
2.2 ANÁLISE ORIENTADA A OBJETOS ...................................................................................13
2.3 O PROJETO ORIENTADO A OBJETOS..............................................................................13
2.4 CLASSES ....................................................................................................................................14
2.5 OBJETOS ..................................................................................................................................15
2.6 ABSTRAÇÃO ...........................................................................................................................15
2.6.1 Abstração de procedimentos ..................................................................................................... 16
2.6.2 Abstração de dados ..................................................................................................................... 16
2.7 ENCAPSULAMENTO..............................................................................................................16
2.8 HERANÇA .................................................................................................................................17
2.9 POLIMORFISMO .....................................................................................................................17
3 UML................................................................................................... 19
3.1 INTRODUÇÃO ..........................................................................................................................19
3.2 HISTÓRICO COMPLETO .......................................................................................................19
3.3 ACEITAÇÃO .............................................................................................................................21
3.4 PADRONIZAÇÃO OMG..........................................................................................................21
3.5 APLICAÇÃO DA UML ............................................................................................................22
4 ETAPAS DE DESENVOLVIMENTO DE UM SISTEMA UTILIZANDO
UML...................................................................................................... 23
4.1 ANÁLISE DE REQUISITOS ...................................................................................................23
4.2 ANÁLISE ...................................................................................................................................25
4.3 PROJETO ..................................................................................................................................25
4.4 PROGRAMAÇÃO ....................................................................................................................25
7
4.5 TESTES .....................................................................................................................................26
5 MODELOS DE ELEMENTOS ............................................................ 27
5.1 DEFINIÇÃO ...............................................................................................................................27
5.2 RELEMBRANDO CLASSES .................................................................................................27
5.2.1 Nomes .............................................................................................................................................. 27
5.2.2 Relembrando atributos ................................................................................................................ 28
5.3 OPERAÇÕES ...........................................................................................................................28
5.3.1 Relembrando objetos ................................................................................................................... 28
5.4 ESTADOS .................................................................................................................................29
5.5 PACOTES .................................................................................................................................29
5.6 COMPONENTES .....................................................................................................................30
5.7 RELACIONAMENTOS ............................................................................................................30
5.8 ASSOCIAÇÕES .......................................................................................................................30
5.8.1 Agregação ....................................................................................................................................... 31
5.8.2 Generalizações .............................................................................................................................. 31
5.8.2.1 Generalização normal ............................................................................................................ 31
5.8.2.2 Generalização restrita ............................................................................................................ 31
5.9 DEPENDÊNCIA E REFINAMENTOS ...................................................................................32
5.10 MECANISMOS GERAIS .......................................................................................................32
6 DIAGRAMAS ..................................................................................... 34
6.1 CONCEITOS .............................................................................................................................34
6.2 Diagrama de Casos de Uso .................................................................................................34
6.3 DIAGRAMA DE CLASSES ....................................................................................................35
6.4 DIAGRAMA DE OBJETOS ....................................................................................................36
6.5 DIAGRAMA DE ESTADOS ....................................................................................................37
6.6 DIAGRAMA DE SEQUÊNCIA ...............................................................................................43
6.7 DIAGRAMA DE COLABORAÇÃO .......................................................................................44
6.8 DIAGRAMA DE ATIVIDADES ...............................................................................................45
6.9 DIAGRAMA DE COMPONENTES ........................................................................................51
6.10 DIAGRAMA DE IMPLANTAÇÃO .......................................................................................51
7 CONCLUSÃO .................................................................................... 53
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................... 54
Referencial Eletrônico .......................................................................... 55
8
1 INTRODUÇÃO
1.1 APRESENTAÇÃO
Os desenvolvimentos do sistema de software de grande porte são suportados
por métodos de análise e projeto que modelam esse sistema de modo a fornecer
para todos os envolvidos (cliente, analista, programador, etc) uma compreensão
única do projeto.
A UML não é uma metodologia de desenvolvimento, o que significa que ela
não diz pra você o que fazer primeiro, qual passo inicial ou como projetar seu
sistema, mas ela auxilia na visualização dele como um todo e a comunicação entre
os objetos. A UML traz novos conceitos que geralmente não são usados, um bom
entendimento dessa linguagem não é somente um conhecimento básico de sua
simbologia e significado, mas também um contexto geral de modelagem orientada a
objetos.
Com a junção das três mais conceituadas metodologia de modelagem
orientada a objetos criou-se a UML, aproveitando o que havia de melhor em cada
um delas, adicionando conceitos e visões da linguagem.
“UML permite criar certos conceitos mais claramente que as linguagens
alternativas” (Fowler, 2000).
Para entendermos melhor, conceituamos UML como uma padronização de
modelagem orientada a objetos, de forma que qualquer sistema possa ser modelado
corretamente, com consistência, fácil de ser entendido, atualizado e compreensível.
Com este trabalho, pretendo justamente, pesquisar sobre esta linguagem de
modelagem, suas aplicações, vantagens e desvantagens.
9
1.2 OBJETIVOS GERAIS E ESPECÍFICOS
Objetivamos de maneira geral com esta pesquisa, o estudo aprofundado
de uma metodologia de modelagem unificada de desenvolvimento de sistemas
orientados a objetos baseados em UML e sua utilização para melhor entendimento
graficamente representado, o nosso sistema de carimbos. Claramente, os objetivos
apresentados são:
Aprofundar nosso estudo sobre UML, obtendo um amplo conhecimento
sobre essa metodologia;
Estudar como se desenvolve uma metodologia de desenvolvimento de
Sistemas;
Mostrar a importância do uso da metodologia no desenvolvimento de
Sistemas; Desenvolver uma metodologia de trabalho baseada em UML;
Mostrar as grandes vantagens da UML utilizando como estudo de caso
situações rotineiras do nosso sistema;
10
1.3 JUSTIFICATIVA
Com o interesse em estudar uma metodologia unificada de desenvolvimento
baseada no nosso sistema, desenvolvemos o presente projeto com o intuito de
apresentar uma metodologia e salientar a importância da sua aplicação, a qual nos
ajuda
resolver
muitos
problemas
encontrados
no
decorrer
de
todo
o
desenvolvimento de um sistema.
1.4 ABRANGÊNCIA
A UML é uma linguagem de desenvolvimento de sistemas orientados a
objetos dominantes, comuns entre os melhores analistas e desenvolvedores.
Pretendemos comprovar a eficácia do uso desta metodologia.
Pontos a serem citados:
A Modelagem de Sistema, usando os conceitos da orientação a objetos;
Estabelecer um método conceitual entre toda equipe envolvida no projeto do
sistema (cliente, analista, desenvolvedor, etc)
Mostrar a qualidade de um sistema desenvolvido utilizando UML.
1.5 METODOLOGIA
Para organizarmos melhor o trabalho, vamos definir as seguintes etapas:
Estudo da Metodologia UML;
Conceitos sobre esta metodologia;
Utilização da metodologia estudada com base no nosso sistema de carimbos;
Estudo e definição de ferramentas para desenvolvimento de sistemas;
Conclusão sobre a metodologia utilizada e sua aplicação;
11
1.6 ESTRUTURA
Este tópico falará um pouco do nosso trabalho e no que constitui cada
capítulo.
No capítulo 2, descreveremos um pouco da análise de projetos orientados a
objetos, necessidades, surgimento, utilização, etc.
Esse capítulo é extremamente importante para o entendimento da análise
orientada a objetos.
No capítulo 3, faremos a introdução a UML (Unified Modeling Language ou
Linguagem de Modelagem Unificada), citaremos sua utilização, o que ela nos
disponibiliza, aceitação, padronização, documentação, atualização e aplicações.
No capítulo 4, falaremos um pouco das etapas técnicas da UML, essas
etapas vão desde o levantamento dos requisitos até, praticamente, o fim do projeto,
que é a fase de testes.
O capítulo 5 traz uma definição de modelos de elementos e descreve
detalhadamente todos os modelos de elementos utilizados pela UML.
O capítulo 6 fala um pouco sobre os diagramas de UML, mostra um pouco
dos 9 tipos de diagramas utilizados pela UML, exemplificando graficamente e
simulando o uso de alguns destes diagramas. Neste capítulo também, você poderá
ver, o uso de dois destes diagramas com teste em diversos cenários no nosso
sistema.
No capítulo 7 faremos as conclusões finais sobre todo o trabalho.
O capítulo 8 traz toda a bibliografia utilizada no desenvolvimento do trabalho.
12
2 ANÁLISE E PROJETOS ORIENTADOS A OBJETOS
2.1 CONCEITOS E HISTÓRIA
Como vimos, a importância da modelagem dentro de um sistema é
indiscutível, ela é a parte central que leva a todas s informações para a implantação
de um bom sistema. Com ela, podemos visualizar e controlar o desenvolvimento de
um sistema de maneira eficaz, identificando e gerenciando riscos, estipulando e
cumprindo prazos, dentro das estimativas de custo.
Tendo como base essas informações iniciais, várias metodologias para o
desenvolvimento de sistemas foram criadas. As primeiras, que foram as
metodologias estruturadas, caracterizam o desenvolvimento de um sistema em torno
de procedimentos e funções. Até os dias de hoje, existem sistemas ainda
desenvolvidos com base em metodologias estruturadas, o que os torna pouco
estáveis, pelo fato de que, à medida que os requisitos vão se modificando com o
crescimento da empresa, a manutenção do sistema, necessária, fica cada vez mais
difícil.
Com a evolução das metodologias, o desenvolvimento de sistemas passou a
ter uma visão diferenciada, com outras perspectivas. Foi nesse momento, que surgiu
as
metodologias
orientadas
a
objetos,
que
caracterizam
o
escopo
do
desenvolvimento do sistema em torno de classes e objetos.
Essa metodologia foi muito bem aceita no mundo dos desenvolvedores,
tendo em vista, que o método orientado a objetos possibilitava a construção de
projetos de sistemas de todos os tipos de domínio e problema, incluindo todos os
graus de tamanho e complexibilidade.
O sucesso da modelagem orientada a objetos foi tão grande, que em pouco
tempo, foram surgindo muitos e muitos métodos, e esse crescimento deu-se de
maneira desordenada em um curto espaço de tempo. Eram inúmeros métodos, cada
um com suas peculiaridades e falhas, e sem nenhum relacionamento com os
demais. Sendo assim, os usuários destes métodos, sentiram a dificuldade de
encontrar um, que atendesse todas as suas expectativas, o que ocasionou a
chamada guerra de métodos.
13
Como toda guerra sempre tem um vencedor, nos métodos não foi diferente.
Tendo os métodos de maior destaque dentre todos, méritos de Jacobson, Booch e
Rumbaugh, surgiu a linguagem de modelagem unificada, a UML.
Porém, a UML é apenas parte de uma metodologia, ela disponibiliza as
ferramentas necessárias para se criar e ler modelos, mas não aponta quais modelos
deverão
ser
criados,
nem
quando
deverão
ser
criados.
Essa
tarefa
é
responsabilidade de um processo de desenvolvimento de sistema.
Mesmo com todo o avanço das metodologias, a UML precisava interagir com
uma metodologia específica que pudesse obter o máximo proveito dos recursos da
Linguagem de Modelagem Unificada, foi criado então o Processo Unificado.
E foi assim que as respostas para quem está fazendo o que, quando e como
puderam ser definidas e um padrão no desenvolvimento de sistemas orientado a
objetos pode ser definido.
2.2 ANÁLISE ORIENTADA A OBJETOS
“Análise é um estudo de um problema antes de qualquer ação” (De Marco,
1978).
Analisar é você identificar as necessidades de um sistema, e o que este
precisa ter para atender os requisitos levantados de acordo com as necessidades do
usuário. Analisar não é definir ou pensar como o sistema será desenvolvido, mas
sim investigar o problema a ser resolvido com a implantação do sistema.
O grande objetivo da Análise Orientada a Objetos é, primeiramente, tornar
formal uma visão do mundo real no qual o sistema será desenvolvido, estabelecendo
os objetos que serão pontos chaves na estrutura organizacional e também as que o
mundo real impõe. Depois, essa análise formaliza a colaboração de um dado
conjunto de objetos na execução do sistema que está sendo desenvolvido.
2.3 O PROJETO ORIENTADO A OBJETOS
O Projeto Orientado a Objetos é o momento da especificação das partes da
construção, ou seja, instruções, guias, recomendações, etc. É utilizado para
implementar um sistema em um ambiente específico, em prol da solução do
problema.
14
2.4 CLASSES
As classes são utilizadas para compor o vocabulário do sistema que está
sendo desenvolvido, através da abstração de objetos que constituem o domínio do
problema.
Vamos exemplificar da seguinte maneira:
As classes são utilizadas para agrupar os objetos que possuem os mesmos
atributos e comportamentos:
“Todos os alunos de uma escola possuem atributos comuns: nome,
sobrenome, data de nascimento, nome da mãe, nome do pai e um comportamento
comum”. Podemos nos referir a um estudante tanto para inscrevê-lo ou retirá-lo. Os
valores destes atributos variam para cada um deles, ou seja, na maioria das vezes,
são
diferentes,
mas
todos
eles
compartilham
os
mesmos
atributos
e
comportamentos (operações podem ser realizadas sobre eles)
Outro exemplo podemos ter uma classe chamada Cachorro, como atributos
a um cão podemos considerar: Nome, Peso e Cor do pelo e as operações ou
métodos, que representam o que esse cachorro faz podemos citar latir e abanar.
Simbolizamos essa classe, seus atributos e operações da seguinte maneira:
FIGURA 1 – CLASSE CACHORRO
15
2.5 OBJETOS
Um objeto representa uma coisa física, tangível, uma idéia ou um
conceito. Um objeto é uma instância de uma classe.
FIGURA 2 – EXEMPLO DE OBJETO
Um objeto pode ser composto por outro objeto, ou mesmo pode pedir a
colaboração de outro objeto enviando uma mensagem, o que denominamos invocar
um método do outro.
2.6 ABSTRAÇÃO
Abstração é o princípio de ignorar os aspectos de um
assunto não relevante para o propósito em questão,
tornando possível uma concentração maior nos assuntos
principais. (Cood, 1991)
Na Análise Orientada a Objetos, podemos considerar duas formas
existentes de abstração, de Procedimentos e de Dados.
16
2.6.1 Abstração de procedimentos
Consiste em considerar um procedimento como uma operação bem
definida, como algo único, mesmo que se utilize mais procedimento interno. Esse
tipo de abstração é utilizado quando uma função se divide em outras sub-funções,
que por sua vez, decompõe-se em outras funções.
2.6.2 Abstração de dados
Consiste em definir um tipo de dado conforme as operações aplicáveis
aos objetos desse tipo, ou seja, a definição de um tipo de dado por seu
comportamento e estado utilizando-se métodos. A manipulação deste dado é
realizada somente através de seu método.
Um exemplo é classificar uma lista a partir das operações aplicadas a ela,
como inserção e remoção. Qualquer objeto do tipo lista, só pode sofrer modificações
através dessas operações.
2.7 ENCAPSULAMENTO
Podemos definir encapsulamento como a separação de um programa em
partes, o mais isoladas possível. O objetivo principal é tornar o software mais
flexível, fácil de modificar e criar novas implementações.
Como exemplo podemos classificar uma dona-de-casa sendo o usuário e
um liquidificador sendo o sistema. A dona-de-casa não precisa conhecer o circuito
interno para utilizar o liquidificador, apenas os botões que o fazem funcionar.
Uma grande vantagem do encapsulamento é que toda parte pode ser
modificada sem que os usuários da classe em questão sejam afetados. No exemplo
anterior, vamos supor que o liquidificador precisou de reparo e a dona-de-casa
chamou um técnico, o técnico poderia facilmente substituir o motor do liquidificador
por outro totalmente diferente sem que a dona-de-casa fosse afetada, pois ela ia
continuar somente pressionando os botões.
17
2.8 HERANÇA
O conceito de herança se refere ao compartilhamento de atributos e
operações com base numa relação hierárquica entre diversas classes. Uma classe
pode ser definida em forma geral e em seguida, refinada em subclasses seguintes.
Cada subclasse herda propriedades (atributos e operações) de suas superclasses.
Representamos da seguinte maneira:
FIGURA 3 – HERANÇA
O objetivo de utilizar a herança é a intenção de aproveitar código ou
comportamento generalizado ou especializar operações ou atributos. O conceito de
herança de várias classes é conhecido como herança múltipla.
Como exemplo pode-se observar as classes 'aluno' e 'professor', onde
ambas possuem atributos como nome, endereço e telefone. Nesse caso pode-se
criar uma nova classe chamada, por exemplo, 'pessoa', que contenha as
semelhanças entre as duas classes, fazendo com que aluno e professor herdem as
características de pessoa, desta maneira pode-se dizer que aluno e professor são
subclasses de pessoa.
“Esta é provavelmente a característica mais discutida da abordagem
orientada a objetos”. (Mazzola, 1999)
2.9 POLIMORFISMO
O termo Polimorfismo foi gerado do grego (poli = muitas e morphos =
formas). Na Análise Orientada a Objetos, o polimorfismo permite que referências de
tipos de classes mais abstratas representem o comportamento das classes
18
concretas que referenciam. Assim, é possível tratar vários tipos de maneira
homogenia (através da interface do tipo mais abstrato).
Um conceito em teoria de tipo no qual um nome
(como uma declaração de variável) pode denotar
objetos de muitas subclasses diferentes que são
relacionadas por alguma superclasse comum,
assim, qualquer objeto denotado por esse nome
tem a capacidade de responder a algum conjunto
comum de operações de modos diferentes.
(Booch, 2000).
19
3 UML
3.1 INTRODUÇÃO
A UML é a 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 e
através
de
diferentes
tecnologias
de
implementação. (Furlan, 1998)
A UML disponibiliza uma forma padrão de modelagem de projetos de
Sistemas, incluindo seus aspectos conceituais tais como processos de negócios e
funções do sistema, além de itens concretos como as classes escritas em
determinada linguagem de programação, processos de banco de dados e
componentes de software reutilizáveis.
3.2 HISTÓRICO COMPLETO
As linguagens de modelagem orientadas a objetos surgiram entre a
metade da década de 1970 e o final da década de 1980, à medida que o pessoal
envolvido com metodologia, diante de um novo gênero de linguagens de
programação orientadas a objeto e de aplicações cada vez mais complexas,
começou a experimentar métodos alternativos de análise e projeto.
A quantidade de métodos orientados a objetos aumentou de pouco mais
de 10 para mais de 50 durante o período de 1989 a 1994. Muitos usuários desses
métodos tiveram dificuldades para encontrar uma linguagem de modelagem capaz
de atender inteiramente às suas necessidades. Destacaram-se algumas linguagens
como o Booch, o OOSE (Object-Oriented Software Engineering) de Jacobson, e o
OMT (Object Modeling Technique) de Rumbaugh. Podemos citar outros métodos
importantes como Fusion, Shlaer-Mellor e Coad-Yourdon.
Todos eram métodos completos, alguns se destacavam em algum ponto,
porém tinham suas limitações. O método Booch destacava-se durante as fases de
projeto e construção de sistemas, o OOSE fornecia excelente suporte para captura
20
de requisitos, a análise e o projeto em alto nível; o OMT-2 era mais útil com a análise
e sistemas de informações com uso de dados[Booch, 2000].
Na metade da década de 1990, Grady Booch (Rational Software
Corporation), Ivar Jacobson (Objectory) e James Rumbaugh (General Electrics)
criadores de métodos orientados a objetos, começaram a pegar as melhores idéias e
partiram para a criação de uma linguagem unificada de modelagem.
Com isso esperavam fornecer ao mercado uma linguagem mais concreta
e madura com os quais os desenvolvedores de ferramentas pudessem criar uma
ferramenta mais utilizável. Usando técnicas orientadas a objeto criariam uma
linguagem que iria desde o conceito até o sistema executável, não somente a
sistemas complexos mas também a sistemas menores e também a outros
problemas que não fossem sistemas de informação, podendo ser utilizado por seres
humanos e máquinas[Furlan, 1998].
A criação da UML iniciou oficialmente em outubro de 1994, quando
Rumbaugh se juntou a Booch na Rational. O foco inicial do projeto era a unificação
dos métodos Booch e OMT[Furlan, 1998]. O esboço da versão 0.8 do Método
Unificado foi lançado em outubro de 1995. Mais ou menos na mesma época
Jacobson se associou à Rational com a finalidade de incorporar o OOSE no escopo
inicial da versão 0.8, resultando o lançamento da versão 0.9 da UML em junho de
1996[Booch, 2000]. Foi então aprovada pela comunidade de engenharia de software
em geral. Muitas empresas ficaram interessadas, foi então criada um consórcio com
várias empresas interessadas em dedicar recursos com o propósito de trabalhar
uma definição mais forte e completa da UML.
Empresas que contribuíram para a definição da UML 1.0, Digital
Equipment
Corporationm
Hewlett-Packard,
I-Logix,
Intel-licorp,
IBM,
ICON
Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments e
Unisys. Resultando uma linguagem de modelagem bem definida , expressiva,
poderosa, e que poderia ser aplicada a uma grande variedade de tipos de problemas
[Booch, 2000]. A UML foi oferecida para a OMG (Object Management Group) em
janeiro de 1997, em resposta à solicitação do próprio OMG de propostas para uma
linguagem padrão de modelagem[Furlan, 1998].
Entre janeiro a julho de 1997, o grupo original se expandiu, passando a
incluir virtualmente todos os participantes e colaboradores da resposta inicial ao
OMG, entre os quais se encontravam Andersen Consulting, Ericson, Object Time
21
Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling
Software e Taskon. Um grupo foi formado, liberado por Cris Kobryn da MCI
Systemhouse e administrado por Ed Eykholt da Rational, com o propósito de
formalizar a especificação da UML e de integrar a linguagem a outros esforços de
padronização. A versão 1.1 foi entregue a OMG em julho de 1997. Em setembro do
mesmo ano, essa versão foi aceita pela ADTF (Analysis and Design Task Force) e
pelo Architecture Board do OMG e, posteriormente submetida a votação de todos os
membros da OMG. A versão 1.1 foi adotada pela OMG em 14 de novembro de
1997[Booch, 2000].
A manutenção da UML foi então assumida pela RTF (Revision Task
Force) do OMG, sob a responsabilidade de Cris Kobryn. A RTF lançou uma revisão
editorial, a UML 1.2., em junho de 1998. No final do mesmo ano, a RTF lançou a
UML 1.3[Furlan, 1998].
3.3 ACEITAÇÃO
Para se estabelecer a UML, os desenvolvedores perceberam que a
linguagem teria que estar acessível para todos, então, preocuparam-se em deixá-la
aberta aos desenvolvedores, onde os mesmos pudessem criar seu próprio método
de trabalho.
Empresas desenvolvedoras de ferramentas estão livres para criarem
uma ferramenta aqueda ao uso da UML. Devido a necessidade de criação da
UML empresas e profissionais liberais da área estão desenvolvendo estudos
para melhor aplicá-la.
3.4 PADRONIZAÇÃO OMG
Quando se iniciaram os trabalhos para criação da UML, os criadores
tinham como intenção fazer sua aceitação com a distribuição da linguagem a vários
desenvolvedores.
A OMG (Object Management Group) fez um requerimento por uma
linguagem de modelagem padrão. Então houve interesse dos criadores da UML em
padronizá-la, para isso foi preciso que os mesmos aprimorassem a qualidade da
22
linguagem para tal. Pois para serem realmente utilizadas por empresas era
necessário sua padronização.
3.5 APLICAÇÃO DA UML
A UML pode ser utilizada para modelar as várias fases de um sistema,
desde o levantamento de requisitos até a geração do código, pode ser aplicada em
qualquer tipo de sistema em termos de diagramas orientado a objeto.
Normalmente. É mais usada na modelagem de Softwares sob o conceito
de orientação a objetos, mas também, pode ser aplicada em sistemas mecânicos, de
engenharia geral, totalmente desligados do ramo da informática, também pode
ajudar na organização de processos de uma empresa.
Numa classificação geral, podemos dizer que ela pode ser aplicada em
várias áreas diferentes para documentar e transmitir qualquer coisa da empresa aos
processos de negócios para o software.
23
4 ETAPAS DE DESENVOLVIMENTO DE UM SISTEMA UTILIZANDO
UML
4.1 ANÁLISE DE REQUISITOS
Um requisito é uma funcionalidade ou condição que o sistema deverá ter,
para não errar no levantamento dos requisitos e os identificar adequadamente,
aplica-se um conjunto de técnicas de modo a perceber detalhadamente o que o
sistema, necessariamente, deverá efetuar.
Fazem parte deste conjunto de técnicas:
Reuniões com os interessados;
Elaboração de questionários sobre o sistema;
Observação das atividades e do funcionamento diário das rotinas da
empresa;
O recolhimento e análise de documentações diversas;
A elaboração de pequenos protótipos do sistema que permitam validar mais
facilmente a percepção obtida (tendo em vista que uma imagem é
fundamental para o entendimento do que vai ser feito);
Preocupação para encontrar a melhor solução;
Analisar, não somente, as funcionalidades atuais, mais também uma
situação futura a ser atingida;
“Esta fase captura as intenções e necessidades dos usuários do sistema
a ser desenvolvido através do uso de funções chamadas use-cases”. (Barros, 2001)
Deve-se sempre ter em vista a “melhor solução”, pois as vezes aquilo que
o utilizador pede não é sempre o que ele necessita.
Através do desenvolvimento de casos de uso (em UML chamamos de
“Use-Cases”), as entidades externas do sistema (em UML chamamos de “atores
externos”) que interagem e possuem interessa no sistema, são modelados entre as
funções que o mesmo vai desenvolver, funções, estas chamadas de “use-cases”. Os
“atores externos” e os “use-case” são modelados através de relacionamentos que
possuem comunicação por associação entre eles ou são desmembrados em
hierarquia. Descrevemos um “use case” através de um texto, especificando os
24
requisitos do ator externo que utilizará esse “use case”. Um “use case” tanto pode
depender de um ou mais “use-case” , como também, pode ter seus dependentes.
Através do diagrama de “use-case” ou “diagrama de casos de uso”
mostraremos aos atores externos, ou seja, futuros usuários, o que estes podem
esperar do sistema.
Vamos exemplificar utilizando um sistema acadêmico, considera-se que
os clientes usuários, professores e secretaria da escola desejam que o sistema
ofereça os seguintes serviços:
Possibilidade de Cadastramento de todos os alunos matriculados
no curso. Isto nos mostra que o sistema deverá ter um serviço de
inclusão de novos alunos e manutenção da base de dados dos
alunos. Esta funcionalidade do sistema poderia ser representada
pelo caso de uso Cadastrar Aluno.
Possibilidade de Cadastramento de todos os professores que
trabalham nesta unidade escolar e ministram disciplina no curso.
Isto nos mostra que o sistema deverá ter um serviço de inclusão de
novos professores e manutenção da base de dados dos
professores.
Esta
funcionalidade
do
sistema
poderia
ser
representada pelo caso de uso Cadastrar Professor.
Possibilidade de registro das disciplinas oferecidas no curso, com a
capacidade de registrar novas disciplinas e a manutenção da base
de dados das disciplinas. Este uso do sistema será representado
pelo caso de uso Cadastrar Disciplina.
Possibilidade de registro da matrícula dos alunos em cada
semestre. Este serviço será representado pelo caso de uso
Registrar Matrícula.
Possibilidade da emissão da confirmação de matrícula para cada
aluno, contendo a lista de disciplinas nas quais um aluno se
matriculou para aquele semestre. Este serviço será representado
pelo caso de uso Emitir Confirmação de Matrícula.
O conjunto de casos de uso definidos representa os serviços ou uso
esperado pelos clientes que utilizaram o sistema. Assim como para os atores, nem
25
sempre é possível efetuar um levantamento completo e definitivo dos casos de uso
em uma primeira tentativa. Ao longo do processo de refinamento, novos casos de
uso poderão aparecer e outros sofrerem alterações.
4.2 ANÁLISE
Nesta fase dominamos somente as classes que pertencem ao domínio
principal do problema, ou seja, classes técnicas mais complexas não estarão nesse
diagrama.
“A fase de análise preocupa-se com as primeiras abstrações(classes e
objetos) e mecanismos presentes no contexto do problema”. (Larman, 2000)
Descrevemos as classes nos Diagramas de Classes e também para
ajudar na descrição dos casos de uso, podendo estar ligado umas nas outras por
meio de relacionamentos.
4.3 PROJETO
Projeto é um esforço temporário empreendido para criar um produto,
serviço ou resultado exclusivo.
Neste momento partiremos para as soluções técnicas, através dos
resultados obtidos nas fases de análise. Serão adicionadas novas classes para
oferecer uma infra-estrutura técnica, tais como: interface do usuário e periféricos,
banco de dados, interação com outros sistemas, e outras mias. Este é o momento
da junção da fase de análise com as classes técnicas da nova infra-estrutura,
podendo assim, alterar tanto o domínio principal do problema quanto a infraestrutura.
É justamente, com a elaboração do projeto que obtemos detalhadamente
as especificações para dar início a fase da programação.
4.4 PROGRAMAÇÃO
Esta fase só terá um bom desempenho se o projeto for muito bem
elaborado, neste momento converteremos as classes da fase do projeto para o
código da linguagem orientada a objetos escolhida.
26
Em UML durante a elaboração dos modelos de análise e projeto, não
devemos traduzi-los em códigos, cabendo esta tarefa a fase de programação.
4.5 TESTES
Na fase de teste, testamos o programa ao máximo na intenção de
descobrir erros. Cada rotina e método são testados minuciosamente, bem como a
integração de todos os processos e a aceitação.
As rotinas devem ser testadas de duas formas, uma pelo programador,
que sabe tudo sobre técnica, pontos críticos das classes e subclasses, e outra pelas
rotinas do usuário, pois ele irá fazer o teste do seu modo, tendo em vista uma visão
da rotina como um todo. Os testes de integração são feitos usando as classes e
seus componentes de integração para verificar se estas classes estão realmente
colaborando uma com as outras conforme especificado nos modelos. Nos testes de
aceitação é verificado se o sistema está de acordo com o especificado no diagramas
de “use-cases”.
Por fim, o sistema é testado pelo usuário final e este verá se o mesmo
está de acordo com suas necessidades expressas no começo do projeto.
27
5 MODELOS DE ELEMENTOS
5.1 DEFINIÇÃO
“Os conceitos utilizados nos diagramas são chamados de modelos de
elementos” (Barros, 2001). Um modelo de elemento é definido com a semântica, a
definição formal do elemento com o exato significado do que ele representa sem
definições duvidosas ou ambíguas e também define sua representação gráfica que é
mostrada nos diagramas da UML.
Um elemento pode aparecer em diversos tipos de diagrama, mas existem
regras que definem quais elementos podem aparecer em tais diagramas. Podemos
citar como exemplos de modelos de elementos: classes, objetos, estados, pacotes
etc. Os relacionamentos também são modelos de elementos e são usados para
conectar outros modelos de elementos entre si.
Para entrarmos definitivamente nesta parte de elementos e diagramas,
precisamos estar desprovidos de dúvidas quanto classes, objetos, estado, etc.
Vamos relembrar!
5.2 RELEMBRANDO CLASSES
Vimos mais acima, que classe é a descrição de um conjunto de objetos
que compartilham os mesmos atributos, relacionamentos, operações e semânticas e
podem ser implantadas em uma ou mais interfaces. Como exemplo demos a classe
cachorro, no capítulo 2, no item 2.4.
5.2.1 Nomes
Todas as classes devem ter um nome que as diferencie das demais.
Como no exemplo do capítulo 2, o nome da nossa classe é cachorro.
28
5.2.2 Relembrando atributos
Vimos que um atributo é uma prioridade de uma classe, que descreve um
intervalo de valores que as instâncias da prioridade podem apresentar. No exemplo
do capítulo 2, usamos como atributos para a nossa classe cachorro os atributos:
Nome, Peso e Cor do Pelo.
5.3 OPERAÇÕES
São processos que as classes podem realizar.
Operações correspondem claramente a métodos em uma classe. No nível
de especificação, as operações correspondem a métodos públicos. Normalmente
você não mostra as operações que simplesmente manipulam atributos, porque elas
podem ser freqüentemente inferidas. Portanto você terá que identificar se um
atributo é somente leitura, isto é, seu valor nunca muda. No modelo de
implementação, você também pode querer mostrar operações privativas (private) e
protegidas (protected).
Uma classe pode ter várias operações ou simplesmente nenhuma, elas
são respresentadas logo após os atributos. No nosso exemplo da classe cachorro,
do capítulo 2, as operações eram latir e abanar.
5.3.1 Relembrando objetos
Vimos que objetos são elementos que podemos manipular, acompanhar
seu comportamento, criar, interagir com ele, ou até, destruí-lo. Ele pode existir no
mundo real ou pode ser uma derivação de estudos da estrutura ou comportamento
de outros objetos do mundo real. Corresponde a qualquer coisa que tenha algum
significado para uma dada aplicação.
29
5.4 ESTADOS
Todos objetos possuem um estado que significa o resultado de atividades
executadas pelo objeto, normalmente este estado é determinado pelos valores dos
atributos e ligações com outros objetos.
Um objeto muda de estado quando algo acontece no sistema, este fato de
mudança de estado de um objeto, chamamos de evento. Analisando essas
mudanças de estado que um objeto pode sofrer, podemos prever todos os possíveis
comportamento de um objeto e os eventos que o mesmo possa sofrer.
Um estado pode ter três compartimentos:
Nome do evento – Mostra o nome do evento, na maioria das vezes este
nome descreve o que este estado realiza.
Atributos – Mostra todas as possíveis variáveis do estado, onde os atributos
do objeto em questão podem ser listados, consultados e atualizados.
Atividades – Aqui, podemos listar os eventos e ações. Esta dividido em três
eventos: Entrar (define as atividades no momento em que o objeto entra
naquele estado), Sair (define as atividades que o objeto executa antes de
passar para o próximo estado) e Fazer (define as atividade que o objeto
executa enquanto se encontra naquele estado).
5.5 PACOTES
“É um mecanismo de propósito geral para organizar elementos de
modelos em grupo, podendo, inclusive, estar aninhando dentro de outros pacotes
(pacotes subordinados)”. (Furlan,1998)
O pacote tem uma grande similaridade com a agregação. O fato de um
pacote ser composto de modelos de elementos cria uma agregação de composição.
Se este for destruído, todo o seu conteúdo também será.
30
5.6 COMPONENTES
Pode ser tanto um código em linguagem de programação, quanto um
código executável já compilado. Exemplo, se um sistema é desenvolvido em Java,
cada arquivo .java ou .class é um componente do sistema, e será mostrado no
diagrama de componentes que o utiliza.
5.7 RELACIONAMENTOS
Ligam classes e objetos entre si, criando relações lógicas entre essas
entidades. Podemos classificá-los em 3 tipos:
Associação – É uma conexão entre as classes, e significa também, uma
conexão entre os objetos daquelas classes. Em UML, uma associação é
definida com um relacionamento que descreve uma série de ligações, onde a
ligação é definida como a semântica, entre as duplas de objetos ligados.
Generalização - É um relacionamento de um elemento mais geral e outro
mais específico. O elemento mais específico pode conter apenas informações
adicionais. Uma instância (um objeto é uma instância de uma classe) do
elemento mais específico pode ser usada onde o elemento mais geral seja
permitido.
Dependência ou refinamentos - Dependência é um relacionamento entre
elementos, um independente e outro dependente. Uma modificação é um
elemento independente afetará diretamente elementos dependentes do
anterior. Refinamento é um relacionamento entre duas descrições de uma
mesma entidade, mas em níveis diferentes de abstração.
5.8 ASSOCIAÇÕES
É uma conexão entre classes, e também significa que é uma conexão
entre objetos daquelas classes. Em UML, uma associação é definida com um
relacionamento que descreve uma série de ligações, onde a ligação é definida como
a semântica entre as duplas de objetos ligados.
31
5.8.1 Agregação
A agregação é um caso particular da associação. A agregação indica que
uma das classes do relacionamento é uma parte, ou está contida em outra classe.
As palavras chaves usadas para identificar uma agregação são: "consiste em",
"contém", "é parte de".
5.8.2 Generalizações
A generalização é um relacionamento entre um elemento geral e um outro
mais específico. O elemento mais específico possui todas as características do
elemento geral e contém ainda mais particularidades. Um objeto mais específico
pode ser usado como uma instância do elemento mais geral. A generalização,
também chamada de herança, permite a criação de elementos especializados em
outros. A generalização pode ser de dois tipos, normal ou restrita.
5.8.2.1 Generalização normal
Na generalização normal a classe mais específica, chamada de subclasse,
herda tudo da classe mais geral, chamada de superclasse. Os atributos, operações
e todas as associações são herdados.
Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela
estiver numa hierarquia de classes que é um gráfico onde as classes estão ligadas
através de generalizações.
A generalização normal é representada por uma linha entre as duas
classes que fazem o relacionamento, sendo que se coloca uma seta no lado da linha
onde se encontra a superclasse indicando a generalização.
5.8.2.2 Generalização restrita
Uma restrição aplicada a uma generalização especifica informações mais
precisas sobre como a generalização deve ser usada e estendida no futuro. As
restrições a seguir definem as generalizações restritas com mais de uma subclasse:
32
Generalizações de Sobreposição e Disjuntiva: Generalização de sobreposição
significa que quando subclasses herdam de uma superclasse por sobreposição,
novas subclasses destas podem herdar de mais de uma subclasse. A generalização
disjuntiva é exatamente o contrário da sobreposição e a generalização é utilizada
como padrão.
Generalizações Completa e Incompleta: Uma restrição simbolizando que uma
generalização é completa significa que todas as subclasses já foram especificadas,
e não existe mais possibilidade de outra generalização a partir daquele ponto. A
generalização incompleta é exatamente o contrário da completa e é assumida como
padrão da linguagem.
5.9 DEPENDÊNCIA E REFINAMENTOS
Dependência é um relacionamento entre elementos, um independente e
outro dependente. Uma modificação a um elemento independente, afetará
diretamente elementos dependentes do anterior. Uma relação de dependência é
simbolizada por uma linha tracejada com uma seta no final em um dos lados do
relacionamento. E sobre essa linha, o tipo de dependência que existe entre essas
duas classes.
Refinamento é um relacionamento entre duas descrições de uma mesma
entidade, mas em níveis diferentes de abstração. Estes, são simbolizados por uma
linha tracejada com um triângulo no final de um dos lados do relacionamento e são
usados em modelos de coordenação. Em projetos maiores, todos os modelos que
são feitos devem ser coordenados. Coordenação de modelos pode ser usada para
mostrar modelos em diferentes níveis de abstração que se relacionam e mostram
também como modelos em diferentes fases de desenvolvimento se relacionam.
5.10 MECANISMOS GERAIS
Para tratar informações adicionais, a UML utiliza alguns mecanismos em
seus diagramas:
Ornamentos: Ornamentos gráficos são anexados aos modelos de elementos
em diagramas e adicionam semântica ao elemento. Como exemplo de
ornamento, podemos citar, a técnica de separar um tipo de uma instância.
33
Quando um elemento representa um tipo, seu nome é mostrado em negrito,
quando o mesmo elemento representa a instância de um tipo, seu nome é
escrito em sublinhado e pode significar tanto o nome da instância, quanto o
tipo.
Notas: Para permitir adicionar informações, a UML provê a capacidade de
adicionar Notas. Uma nota pode ser colocada em qualquer lugar em um
diagrama, e pode conter qualquer tipo de informação.
34
6 DIAGRAMAS
6.1 CONCEITOS
O objetivo de se fazer modelagem, é você simplificar a realidade para um
melhor entendimento do sistema que está sendo desenvolvido. Em UML,
utilizamos blocos distintos, tais como: classes, interfaces, colaborações,
componentes, dependências, associações, etc. Os diagramas são para
visualizarmos os blocos em construção.
Os diagramas utilizados em UML são separados em nove tipos: Diagrama
de Casos de Uso, Classes, Objetos, Estados, Seqüência, Colaboração,
Atividades, Componentes e Execução. Na seqüência trataremos cada um desses
tipos de Diagrama e citaremos dois, detalhadamente, mostrando graficamente
gráficos apresentando rotinas diretas do nosso sistema de carimbos.
6.2 Diagrama de Casos de Uso
“Um diagrama de caso de uso, ilustra um conjunto de casos de uso, para
um sistema, os atores e a relação entre os atores e os casos de uso”.
(Larman,2000).
Esse tipo de diagrama é utilizado pra mostrar como a empresa ou o
sistema funciona, ou como os usuários desejam que ele funcione. Os caso de
uso, geralmente são ponto de partida na análise orientada a objetos na UML.
Esse modelo consiste de atores e casos de uso. Os atores representam
usuário e outros sistemas que interagem com o modelado. Geralmente,
representamos o ator, dentro de um diagrama por um homem palito. Os casos de
uso mostram como o sistema se comporta, cenários que ele percorre em
resposta ao estímulo do ator. Representamos os casos de uso por elipses.
No modelo de caso de uso, o relacionamento entre um ator e um caso de
uso representa a participação deste ator no caso de uso. Além deste
relacionamento, existem dois outros tipos de relacionamento entre casos de uso:
35
Estender : É representado graficamente por uma seta com o esteriótipo
<<extends>>, que nos permite entender que o caso de uso destino pode
incluir o comportamento especificado pelo caso de uso origem;
Usar: Representado por uma seta com o esteriótipo <<uses>>, nos
permite entender que o caso de uso origem inclui o comportamento do
caso de uso destino.
Incluir: Representado por uma seta com o esteriótipo <<include>> é
utilizado para incluir um comportamento comum de um caso de uso
incluído para um caso de uso base, a fim de suportar a reutilização do
comportamento comum.
Exemplo de Diagrama de Caso de Uso:
FIGURA 4 – DIAGRAMA DE CASO DE USO
6.3 DIAGRAMA DE CLASSES
Representamos uma classe em UML, com uma caixa retangular com três
divisões: Nome da Classe, Lista de Atributos, e o último com Operações, como
vimos no capítulo 2, a classe Cachorro.
As associações representam relacionamentos estruturados entre os
objetos de diferentes classes, e são representados graficamente através de uma
linha conectando as classes. Uma associação pode ter um nome. E nas
36
extremidades da linha, que representa uma associação pode ter nome de papéis
mostrando como a classe é vista pelas outras classes na associação.
A multiplicidade especifica quantas instâncias de uma classe relaciona-se
a uma única instância de uma classe associada. A multiplicidade é representada
por
um
intervalo
de
valores
possíveis,
no
seguinte
formato:
limite_inferior...limite_superior, onde esses limites são valores inteiros (o caracter
* pode ser usado como limite_superior para indicar falta de limite).
A agregação é uma forma especial de associação que representa o
relacionamento todo-parte entre objetos. Ela é representada incluindo-se um
losango na extremidade do objeto todo do relacionamento todo-parte.
A generalização é uma ferramenta poderosa para a abstração. É um
relacionamento existente entre uma classe mais geral (superclasse) e uma
classe mais específica (subclasse), onde a classe mais específica é consistente
com a mais geral e adiciona informações a ela. A generalização é representada
por uma linha com um triângulo, que liga a classe mais específica a mais
genérica.
Exemplo de Diagrama de Classes:
FIGURA 5 – DIAGRAMA DE CLASSE
6.4 DIAGRAMA DE OBJETOS
Fazem a modelagem de instância de itens contidos em diagrama de
classes. Mostra um conjunto de objetos e seus relacionamentos em determinado
37
ponto no tempo. Estes diagramas não são importantes apenas para a
visualização, especificação e documentação de modelos estruturais, mas
também para a construção de aspectos estático de sistemas por meio de
engenharia de produção e engenharia reversa [Booch, 2000].
Este tipo de diagrama cobrem um conjunto de instâncias dos itens
encontrados nos diagramas de classes. Portanto, esse diagrama expressa a
parte estática de uma interação, composta pelos objetos que colaboram entre si,
mas sem qualquer uma das mensagens passadas entre eles. Nos dois casos, o
Diagrama de Objetos congela um momento no tempo.
São usados para fazer a modelagem da visão de projeto estática ou da
visão de processo estática de um sistema, da mesma forma como faz os
diagramas de classes, mas a partir da perspectiva de instâncias reais ou
prototípicas. Este tipo de diagrama permite que você faça a modelagem de dados
estáticos.
Vejamos um exemplo de Diagrama de Objetos:
FIGURA 6 – DIAGRAMA DE OBJETOS
6.5 DIAGRAMA DE ESTADOS
São usados para modelar o comportamento dinâmico de um sistema.
Mostram o ciclo de vida de um objeto em níveis de detalhe arbitrariamente
simples ou complexos [Larman, 2000].
38
Visualizam a seqüência de estados que um objeto ou uma interação
percorre durante sua vida em resposta a estímulos recebidos, junto com suas
próprias ações e respostas.
Os estados representam as condições dos objetos em um determinado
momento.
Neste diagrama os eventos são incidentes que fazem o objeto mudar de
um estado para outro. As linhas de transição descrevem o movimento de um
estado para outro. Cada linha de transição é rotulada com o evento que causou a
transição.
Estudamos o Diagrama de Estados para que pudéssemos visualizar
melhor todos os estados que passavam os objetos do diagrama da empresa de
carimbos durante ações rotineiras do sistema, portanto, vamos mostrar mais de
um exemplo neste diagrama, que se trata do nosso sistema.
39
Exemplo 1 – Construímos estes diagramas de acordo com nosso sistema.
Utilizamos para isso duas ações de rotina que são Cadastrar Venda e cadastrar
Preços.
Cadastrar Venda
Inicio das
operações
Cadastrar Preços
Inicio das
operações
Digitando os dados da
Venda
ValidandoDados()
Concluindo a venda
ValidandoDados()
Efetuando a Venda
Fim das
operações
FIGURA 7 – CADASTRAR VENDAS E PREÇOS
Digitando os dados dos
preços
ValidandoDados()
Concluindo o cadastro
ValidandoDados()
Efetuando o cadastro
Fim das
operações
40
Exemplo 2 – Diagrama de Estado Cadastrar Cliente e Cadastrar Fornecedor
Cadastrar Cliente
Cadastrar Fornecedor
Inicio das
operações
Inicio das
operações
Digitando os dados do
cliente
ValidandoDados()
Concluindo o cadastro
ValidandoDados()
Efetuando o cadastro
Fim das
operações
FIGURA 8 – CADASTRAR CLIENTE E FORNECEDOR
Digitando os dados do
fornecedor
ValidandoDados()
Concluindo o cadastro
ValidandoDados()
Efetuando o cadastro
Fim das
operações
41
Exemplo 3. Diagrama de Estado Cadastrar Débito e Cadastrar Credito.
Cadastrar Debito
Cadastrar Credito
Inicio das
operações
Inicio das
operações
Preparando os dados
para o debito
Preparando os dados
para o credito
Efetuando debito
Efetuando credito
Concluindo o debito
Concluindo o credito
FIGURA 9 – CADASTRAR DÉBITO E CRÉDITO
42
Exemplo 4 – Diagrama de Estado Cadastrar Produto e Cadastrar Usuário
Cadastrar Produto
Cadastrar Usuário
Inicio das
operações
Inicio das
operações
Digitando os dados do
produto
ValidandoDados()
Concluindo o cadastro
ValidandoDados()
Efetuando o cadastro
Fim das
operações
FIGURA 10 – CADASTRAR PRODUTO E USUÁRIO
Digitando os dados do
usuário
ValidandoDados()
Concluindo o cadastro
ValidandoDados()
Efetuando o cadastro
Fim das
operações
43
Exemplo 5 – Diagrama de Estado Cadastrar Movimentação e Cadastrar Pedido
Cadastrar Movimentação
Cadastrar Pedido
Inicio das
operações
Inicio das
operações
Preparando os dados
para movimentação
Preparando os dados
para o pedido
Efetuando a
movimentação
Efetuando o pedido
Concluindo a
movimentação
Concluindo o pedido
Fim das
operações
Fim das
operações
FIGURA 11 – CADASTRAR MOVIMENTAÇÃO E PEDIDO
6.6 DIAGRAMA DE SEQUÊNCIA
São usados para modelar a interação entre objetos dentro de um sistema,
tipicamente, este tipo de diagrama captura o comportamento de um único caso de
uso. O Diagrama apresenta os objetos e as mensagens que são passadas entre
estes objetos dentro caso de uso. Os objetos são representados por linhas
tracejadas verticais e a passagem de mensagens entre dois objetos são
representados
por
vetores
horizontais.
As
cronologicamente do topo a base do diagrama.
mensagens
são
desenhadas
44
Exemplo de Diagrama de Seqüência
FIGURA 12 – DIAGRAMA DE SEQUÊNCIA
6.7 DIAGRAMA DE COLABORAÇÃO
É uma outra alternativa para a modelagem de interações entre objetos de
um sistema. Esse tipo de diagrama focaliza no relacionamento entre os objetos e na
compreensão dos efeitos sobre um objeto durante um cenário. Os objetos são
conectados através de associações e cada associação representa uma instância de
associação entre as respectivas classes envolvidas. As associações mostram as
mensagens enviadas entre os objetos, e a seqüência destas mensagens é
determinada usando-se números seqüenciais.
O Diagrama de Colaboração dá ênfase à ordenação estrutural em que as
mensagens são trocadas entre os objetos de um sistema.
Exemplo de Diagrama de Colaboração:
FIGURA 13 – DIAGRAMA DE COLABORAÇÃO
45
6.8 DIAGRAMA DE ATIVIDADES
Este
tipo
de
diagrama
representa
os
fluxos
conduzidos
por
processamento, é essencialmente um gráfico de fluxo de controle de uma atividade
para outra, comumente isso envolve a modelagem das etapas seqüenciais de um
processo computacional. Este tipo de Diagrama é extremamente importante para a
construção de sistemas executáveis por meio de engenharia de produção reversa. O
principal objetivo deste diagrama é focar nos fluxos dirigidos pelo processamento
interno e descrever o comportamento de processamentos paralelos.
São usados para detalhar classes, implementação de operações e casos
de uso, enquanto os diagramas de estado são usados para especificar o
comportamento global de um tipo. Esse tipo de diagrama representa o que
acontece, mas não quem faz o que, isso nos leva a crer que esse tipo de diagrama
não diz qual classe é responsável por qual atividade.
Testamos nosso sistema de Carimbos utilizando também, o diagrama de
atividades. Segue abaixo os resultados.
46
Exemplo de Diagrama de Atividades de Venda e Preço da empresa de carimbos:
CADASTRAR VENDA - CADASTRAR PREÇOS
FIGURA 14 – CADASTRAR VENDAS E PREÇOS
47
Exemplo 2 – Diagrama de Atividades de Cliente e Fornecedor
CADASTRAR CLIENTE - CADASTRAR FORNECEDOR
FIGURA 15 – CADASTRAR CLIENTE E FORNECEDOR
48
Exemplo 3 – Diagrama de Atividades de Débito e Crédito
CADASTRAR DÉBITO - CADASTRAR CRÉDITO
FIGURA 16 – CADASTRAR DÉBITO E CRÉDITO
49
Exemplo 4 – Diagrama de Atividades de Produto e Usuário
CADASTRAR PRODUTO - CADASTRAR USUÁRIO
FIGURA 17 – CADASTRAR PRODUTO E USUÁRIO
50
Exemplo 5 – Exemplo de Diagrama de Atividades de Movimentação e Pedido
CADASTRAR MOVIMENTAÇÃO - CADASTRAR PEDIDO
FIGURA 18 – CADASTRAR MOVIMENTAÇÃO E PEDIDOS
51
6.9 DIAGRAMA DE COMPONENTES
“Mostram dependências entre componentes de software”. (Furlan,1998).
Os diagramas de componentes representam, de forma estática, aspectos
físicos do sistema sendo modelado. São importantes tanto para visualizar,
especificar e documentar sistemas baseados em componentes quanto para construir
sistemas através de engenharia reversa (reverse) e direta (forward).
São tipicamente usados para:
Modelar a organização do código fonte;
Modelar lançamentos de executáveis;
Modelar fisicamente um banco de dados;
Modelar sistemas adaptativos;
Engenharia de produção e engenharia reversa;
Exemplo de Diagrama de Componentes:
FIGURA 19 – DIAGRAMA DE COMPONENTES
6.10 DIAGRAMA DE IMPLANTAÇÃO
Os diagramas de implantação são diagramas que mostram a configuração
de nós de processamento em tempo de execução e os componentes que neles
existem.
Os diagramas de implantação não são importantes somente para
visualizar, especificar e documentar sistemas embutidos, cliente/servidor e
distribuídos, mas também para o gerenciamento de sistemas por engenharia de
produção e engenharia reversa.
52
Os diagramas de implantação são empregados para modelagem da visão
estática de implantação de um sistema. Essa visão direciona primariamente a
distribuição, entrega e instalação das partes que formam o sistema físico. Na maior
parte, isso envolve a modelagem da topologia do hardware em que o sistema é
executado. Os diagramas de implantação são essencialmente diagramas de classes
que focalizam os nós do sistema.
Exemplo de Diagrama de Implantação:
FIGURA 20 – DIAGRAMA DE IMPLANTAÇÃO
53
7 CONCLUSÃO
Após toda a pesquisa e estudo para o desenvolvimento deste trabalho,
afirmo que o uso de uma metodologia unificada para o desenvolvimento de sistemas
mais complexos, torna-se indispensável. Pois esse tipo de metodologia facilita tanto
a comunicação entre toda equipe envolvida (cliente, programador, analista, etc)
quanto à documentação (toda parte de requisitos e código-fonte).
Montamos o diagrama de alguns cenários rotineiros do nosso sistema de
carimbos, o que nos retornou um entendimento amplo dos caminhos que o sistema
percorre até exibir o resultado final para o usuário que dá apenas um clique.
Foi fundamental um estudo mais detalhado sobre o Diagrama de Estados
e o de Atividades para testarmos nosso sistema, o de Atividades nos fez
compreender todo o fluxo da atividade em um único processo. Já o de Estado, nos
mostrou os possíveis estados de um objeto e as transações responsáveis pelas suas
mudanças de estado.
54
REFERÊNCIAS BIBLIOGRÁFICAS
FOWLER, Martin. UML, Distilled Third Edition, 2004.
JIMENÉZ, Alberto Taboada. Fundamentos UML, 2007.
VIDEIRA, Alberto Silva Carlos. UML, Metodologias e Ferramentas Case, Portugal,
2001
55
Referencial Eletrônico
http://tadeujnr.sites.uol.com.br/pcc/txt_uml.html
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/estado/diag_es
tados.htm
http://docs.kde.org/stable/pt_BR/kdesdk/umbrello/uml-elements.html
http://www.4shared.com – Download de Livros e Apostilas
http://www.slideshared.net
http://www.maxcnunes.com
http://en.wikipedia.org/wiki/Knowledge