UML UML (Unified Modeling Language ou Linguagem de modelagem
unificada) Linguagem padro para modelagem orientada a objetos.
Permite visualizao do trabalho do desenvolvedor atravs de Diagramas
Uma linguagem comum e amplamente utilizvel Utiliza-se de um
conjunto de tcnicas de notao grfica para criar modelos visuais de
software de sistemas intensivos
Slide 4
DIAGRAMA DE CASOS DE USO Tem o Objetivo de auxiliar a comunicao
entre o cliente e os analistas Descreve um cenrio que mostra as
funcionalidade do sistema do ponto de vista do usurio Deve conter
para o cliente ver as principais funciona- lidades de seu sistema.
Representa o conjunto de comportamentos de alto nvel que o sistema
deve executar para um determinado ator o diagrama mais simples, e
no h necessidade de grandes detalhamentos.
Slide 5
Slide 6
DIAGRAMA DE CLASSES Representa uma coleo de classes e seus
inter- relacionamentos pode oferecer trs perspectivas, cada uma
para um tipo de observador diferente: - Conceitual: Representa os
conceitos do domnio em estudo e perspectiva destinada ao cliente -
Especificao: Foco nas principais interfaces da arquitetura e no
como eles iro ser implementados - Implementao: A mais utilizada de
todas, Aborda vrios detalhes de implementao, tais como
navegabilidade, tipo dos atributos, etc.
Slide 7
Slide 8
DIAGRAMA DE PACOTES Descreve os pacotes ou pedaos do sistema
divididos em agrupamentos lgicos mostrando as dependncias entre
estes Muito utilizado para ilustrar a arquitetura de um sistema
mostrando o agrupamento de suas classes Um pacote representa um
grupo de classes (ou outros elementos) que se relaciona com outros
pacotes atravs de uma relao de dependncia Pode ser utilizado em
qualquer fase do processo de modelagem e visa organizar os
modelos
Slide 9
Slide 10
DIAGRAMA DE INTERAO So modelos que descrevem como grupos de
objetos colaboram em algum comportamento. Tipicamente, um diagrama
de interao captura o comportamento de um nico caso de uso. O
diagrama mostra vrios objetos e as mensagens que so passadas entre
estes objetos em um caso de uso. Existem dois tipos de diagramas de
interao: Diagramas de sequencia e diagramas de colaborao.
Slide 11
DIAGRAMAS DE SEQUNCIA Tem o objetivo de mostrar como as
mensagens entre os objetos so trocadas no decorrer do tempo para a
realizao de uma operao Linhas verticais representando o tempo de
vida de um objeto (lifeline) Estas linhas verticais so preenchidas
por barras verticais que indicam exatamente quando um objeto passou
a existir. Quando um objeto desaparece, existe um "X" na parte
inferior da barra Linhas horizontais ou diagonais representando
mensagens trocadas entre objetos. Estas linhas so acompanhadas de
um rtulo que contm o nome da mensagem e, opcionalmente, os
parmetros da mesma Uma condio representada por uma mensagem cujo
rtulo envolvido por colchetes; Mensagens de retorno so
representadas por linhas horizontais tracejadas. Este tipo de
mensagem s deve ser mostrada quando for fundamental para a clareza
do diagrama.
Slide 12
Slide 13
DIAGRAMA DE COLABORAO A grande diferena entre um diagrama de
colaborao e um de sequencia consiste no fato de que o tempo no mais
representado por linhas verticais, mas sim atravs de uma numerao,
que pode ser de duas formas: Simples (1,2,3,...) e Composta (1.1,
1.2, 1.2.1,...) Um objeto representado como um retngulo, contendo
no seu interior um rtulo, que informa o nome do objeto e o nome da
classe, separados por dois pontos. A troca de mensagens entre os
objetos segue o mesmo padro que o apresentado nos diagramas de
sequencia.
Slide 14
Slide 15
DIAGRAMA DE ESTADO Em um diagrama de estado, um objeto possui
um comportamento e um estado O estado de um objeto depende da
atividade na qual ele est processando Um diagrama de estado mostra
os possveis estados de um objeto e as transaes responsveis pelas
suas mudanas de estado.
Slide 16
Slide 17
DIAGRAMA DE ATIVIDADES essencialmente um grfico de fluxo,
mostrando o fluxo de controle de uma atividade para outra e sero
empregados para fazer a modelagem de aspectos dinmicos do sistema
Enquanto os diagramas de sequencia do nfase ao fluxo de controle de
um objeto para outro, os diagramas de atividades do nfase ao fluxo
de controle de uma atividade para outra; Uma atividade uma execuo
no atmica em andamento em uma mquina de estados e acabam resultando
em alguma ao, formada pelas computaes atmicas executveis que
resultam em uma mudana de estado do sistema ou o retorno de um
valor.
Slide 18
Slide 19
DIAGRAMA DE OBJETOS Uma variao do diagrama de classes e utiliza
quase a mesma notao. A diferena que o diagrama de objetos mostra os
objetos que foram instanciados das classes como se fosse o perfil
do sistema em certo momento de sua execuo Os objetos so escritos
com seus nomes sublinhados e todas as instncias num relacionamento
so mostradas so muito teis para exemplificar diagramas complexos de
classes ajudando muito em sua compreenso Tambm so usados como parte
dos diagramas de colaborao onde a colaborao dinmica entre os
objetos do sistema so mostrados.
Slide 20
Slide 21
DIAGRAMA DE COMUNICAO Era conhecido como Diagrama de Colaborao
at a verso 1.5 da UML, o seu nome modificado na verso 2.0
Amplamente associado ao Diagrama de Sequencia, na verdade, um
complementa o outro As informaes mostradas so, com frequncia,
praticamente as mesmas apresentadas no Diagrama de Sequencia, porm
com um enfoque diferente, visto que este diagrama no se preocupa
com a linha de tempo do processo, concentrando-se em como os
objetos so vinculados e quais mensagens trocam entre si durante o
processo.
Slide 22
Slide 23
DIAGRAMA DE COMPONENTES Mostra o sistema por um lado funcional,
expondo as relaes entre seus componentes e a organizao de seus
mdulos Descreve os componentes e as dependncias, representando a
estrutura do cdigo gerado Os componentes tambm podem ser uma
tabela, documentos, outros sistemas. Todo este conjunto ir compor o
sistema Um componente representado como um retngulo e dois pequenos
retngulos do lado esquerdo e o nome do componente pode ser escrito
dentro ou abaixo do componente. Os componentes podem ser
implementados por meios diferentes de arquivos, linguagens de
programao, tabelas, equipamentos. Para determinar o tipo do
componente usamos esteretipos.
Slide 24
Slide 25
DIAGRAMA DE IMPLANTAO Representa a configurao e a arquitetura
do sistema em que estaro ligados os respectivos componentes. Tambm
podemos representar toda a estrutura de hardware e requisitos
mnimos onde o sistema ser executado. Principais caractersticas so:
- Pode representar a estrutura da plataforma em que ser utilizado;
- Pode representar bancos de dados, Componentes de Terceiros; -
Pode representar os servidores, a rede; - Pode representar a
configurao dos equipamentos; No especfico do desenvolvedor, mas em
uma equipe onde existe o responsvel pela implantao do sistema, este
deve estar preocupado com o hardware e a configurao em que o
sistema dever ser executado e a compatibilidade entre os dois.
Slide 26
Slide 27
DIAGRAMA DE ESTRUTURA COMPOSTA utilizado para modelar
Colaboraes Colaborao descreve uma viso de um conjunto de entidades
cooperativas interpretadas por instncias que cooperam entre si para
executar uma operao especfica Este diagrama tambm pode ser
utilizado para definir a estrutura interna de um classificador Este
um dos novos diagramas propostos pela UML 2.0
Slide 28
Slide 29
DIAGRAMA DE TEMPO OU TEMPORIZAO Este diagrama descreve a mudana
no estado ou condio de uma instncia de uma classe ou seu papel
durante um tempo Tipicamente utilizado para demonstrar a mudana no
estado de um objeto no tempo em resposta a eventos externos.
Slide 30
Slide 31
FERRAMENTAS CASE NA UML O termo CASE (Computer-aided software
engineering) significa engenharia de software auxiliada por
computador. Ferramenta CASE um software que auxilia no ciclo de
desenvolvimento de um sistema, desde a fase de anlise, fase de
testes, desenvolvimento e apoiam na manuteno de metodologias
Armazenam as informaes de uma forma prpria, como textos, imagens,
grficos, possibilitando a integrao com o usurio.
Slide 32
FERRAMENTAS CASE NA UML As ferramentas CASE dividem-se em 3
tipos: Integrated System CASE (I-CASE), que visam desde a anlise at
a gerao do cdigo. Cases de automao de uma fase ou mais do
desenvolvimento. So ferramentas que se prendem a uma etapa do
projeto, como por exemplo Ferramentas para modelagem de dados.,
Ferramenta de testes. Ferramentas que seguem uma metodologia
especfica, como por exemplo ferramentas para Scrum, XP.
Slide 33
Algumas vantagens que podemos ver no uso de ferramentas CASE
so: Maior qualidade nos produtos finais; Produtividade; Eliminao de
retrabalho; Mais tempo para a tomada de deciso; Flexibilidade para
mudanas; Melhor documentao; Manuteno mais fcil e gil; FERRAMENTAS
CASE NA UML
Slide 34
ANLISE OO: MODELAGEM ESTTICA So etapas sequencias de passos bem
definidos que auxiliam a especificao do modelo de analise de
sistema de software a partir dos requisitos estabelecidos Esses
requisitos so especificados atravs dos casos de uso Apesar das
ideias apresentadas serem genricas o suficiente para possibilitar a
sua utilizao conjunta com outros artefatos de descrio de
requisitos
Slide 35
ANLISE OO X PROJETO OO Uma das partes mais importantes de um
processo de desenvolvimento de software o conjunto de diretrizes
que sugere como decompor sistemas grandes e complexos em
componentes menores que possam ser manipulados mais facilmente. A
aplicao de conceitos de orientao a objetos para o desenvolvimento
de software traz novas solues para velhos problemas, mas tambm
demanda a confeco de novos mtodos e processos que adotem uma
abordagem completamente nova. Sendo assim, um processo de
desenvolvimento de software orientado a objetos difere dos
processos tradicionais na maneira particular como decompe o sistema
em partes menores e na natureza dos relacionamentos entre essas
partes.
Slide 36
Alm disso, numa abordagem clssica, as fases de anlise, projeto,
implementao e testes so geralmente vistas como fases globais e
separados a serem executados sequencialmente no ciclo de vida do
sistema inteiro. Na abordagem orientada a objetos, essa ideia no se
aplica. A sequencia de fases de anlise, projeto, implementao e
testes pode ser adotada para o ciclo de vida de classes
individuais, e no necessariamente para o sistema inteiro como na
abordagem clssica. existe uma distino comum feita entre anlise
orientada a objetos e projeto orientado a objetos. Em geral, a fase
de anlise lida com o domnio do problema, enquanto que a fase de
projeto lida com o domnio da soluo. ANLISE OO X PROJETO OO
Slide 37
DESCRIO DOS TERMOS Anlise OO. Modela o mundo real de tal modo
que ele possa ser compreendido. Durante a anlise, a nfase est em
encontrar e descrever as entidades do domnio do problema que sejam
relevantes para o sistema que se pretende construir. Projeto OO.
Define as entidades de software que fazem parte do domnio da soluo
e que sero implementa- das em uma linguagem de programao orientada
a objetos. ANLISE OO X PROJETO OO
Slide 38
O modelo de anlise uma abstrao do modelo de projeto. Graas sua
abstrao, o modelo de anlise omite vrios detalhes de como o sistema
funciona e proporciona um panorama geral da funcionalidade do
sistema. Por ser um refinamento do modelo de anlise, o modelo de
projeto consiste de um conjunto de colaboraes que representam a
estrutura e o comportamento do sistema, de forma mapeavel a pelo
menos uma linguagem de programao orientada a objetos. A maneira
como o sistema se comporta derivada do modelo de casos de uso e dos
requisitos no funcionais especificados para ele. ANLISE OO X
PROJETO OO
Slide 39
Modelagem Esttica x Modelagem Dinmica A anlise orientada a
objetos cria uma especificao que utiliza termos e entidades do
domnio do problema para represent-la principalmente os requisitos
funcionais do sistema. Durante a anlise, so modelados aspectos
estticos e dinmicos do domnio do problema. Na modelagem esttica,
conceitos do mundo real relevantes para o sistema a ser construdo
so includos em um dia- grama de classes de anlise, tambm conhecido
como modelo de objetos ou modelo conceitual. Basicamente, esse
modelo composto das principais entidades do sistema (classes), os
atributos dessas classes e os relacionamentos entre elas.
Slide 40
A modelagem dinmica descreve os aspectos do sistema de software
que podem mudar com o tempo devido ocorrncia de eventos e que dizem
respeito ao seu fluxo de controle. A modelagem dinmica usa
diagramas dinmicos de UML, como diagramas de sequencia, de
atividades e de colaborao, para modelar as interaes entre objetos
no sistema. Esses objetos so instancias das classes de anlise e
esto contidos no domnio do problema. A modelagem dinmica tambm
afeta o modelo de classes de anlise, enriquecendo-o com elementos
ligados ao comportamento do sistema, como as operaes. Modelagem
Esttica x Modelagem Dinmica
Slide 41
Slide 42
OMT A OMT (OBJECT MODELING TECHNIQUE) uma metodologia de
desenvolvimento de software orienta- da a objetos que abrange desde
a etapa de anlise, passando pelo projeto, at a implementao. Como
qualquer outra metodologia orientada a objetos, a OMT enxerga um
software como sendo um conjunto organizado de objetos discretos que
possuem estru- turas de dados e um determinado comportamento.
Slide 43
A OMT prope quatro etapas para o desenvolvimento de um software
orientado a objetos: ANLISE: Parte-se da declarao do problema para
se modelar uma situao do mundo real. O modelo produzido nesta etapa
deve representar O QUE o sistema desejado deve fazer e no COMO
fazer. Nesta etapa, no se deve ficar restrito aos aspectos de
implementao em computador e sim enfocar todos os aspectos do domnio
da aplicao, independentemente de virem ou no a ser automatizados.
DESENHO DO SISTEMA: Nesta etapa, decide-se a arquitetura do sistema
e a plataforma onde ele vai rodar. Decompe-se o sistema em
subsistemas, projetam-se aspectos de performance e da interface
homem/mquina. ETAPAS DA METODOLOGIA OMT
Slide 44
DESENHO DOS OBJETOS: Baseando-se no modelo produzido na etapa
de anlise, elabora-se um modelo de objetos, contendo detalhes de
implementao. Os detalhes adicionados devem estar de acordo com as
estratgias de implementao estabelecidas na etapa de desenho do
sistema. IMPLEMENTAO: As classes de objetos e respectivos
relacionamentos projetados durante a etapa de desenho dos objetos
so finalmente transformados em programas de computador, em uma
determinada linguagem de programao, utilizando um determinado
gerenciador de bases de dados e para serem processados em um
determinado tipo de plataforma computacional. ETAPAS DA METODOLOGIA
OMT
Slide 45
OS TRS MODELOS DA OMT A metodologia OMT faz uso de trs tipos de
modelos para representar um sistema: O MODELO DE OBJETOS: Descreve
a estrutura esttica dos objetos e seus relacionamentos em um
sistema. muito parecido, embora com mais riqueza de significantes,
com o clssico modelo de entidades-relacionamento. O MODELO DINMICO:
Descreve a evoluo dos componentes do sistema ao longo do tempo, ou
seja, busca representar o ciclo de vida dos objetos do sistema.
Utiliza-se, como ferramenta de representao do modelo dinmico, o
Diagrama de Transio de Estados. O MODELO FUNCIONAL: Descreve os
fluxos de dados de entrada e sada do sistema e os processos que
transformam os dados de entrada, produzindo os dados de sada.
Utiliza-se o Diagrama de Fluxo de Dados para se construir o modelo
funcional.
Slide 46
MODELOS DE OBJETOS SIMBOLOGIA Cada componente ou associao
pertencente ao modelo de objetos utiliza uma forma de representao
grfica na forma como est resumido abaixo:
Slide 47
Cada objeto est em um determinado estado (situao) em um
determinado instante do tempo. Muda para outro estado quando ocorre
um evento especfico. MODELOS DINMICOS (SIMBOLOGIA)
Slide 48
RUP O RUP (Rational Unified Process) uma metodologia para
desenvolvimento de software criada pela Rational Software, IBM,
SofTeam, Unisys, Nihon Unisys, Alcatel e Q-Labs. O RUP pode ser
encontrado na forma de um software, fornecido pela Rational
Software, e como um conjunto de processos. o RUP mais do que um
softwares para auxiliar no desenvolvimento uma metodologia de
desenvolvimento, com uma estrutura formal e bem definida. Como
qualquer metodologia, composta de conceitos, prticas e regras. Um
dos principais pilares do RUP o conceito de best practices
(melhores prticas), que so regras/prticas que visam reduzir o risco
(existente em qualquer projeto de software) e tornar o
desenvolvimento mais eficiente.
Slide 49
RUP O RUP define seis best practices, sendo elas: Desenvolver
iterativamente Gerenciar requerimentos Utilizar arquiteturas
baseadas em componentes Modelar visualmente Verificao contnua de
qualidade Controle de mudanas O RUP, ainda, entrelaa o conceito de
best practices em quatro definies, sendo elas: Funes: grupos de
atividades executadas. Disciplinas: reas de esforo na engenharia de
software. Atividades: definies de como (objetos/artefatos)
construdo e avaliado. Objetos/artefatos: resultado do trabalho,
produzido ou modificado durante o processo.
Slide 50
RUP Divide o processo de desenvolvimento de software em quatro
fases Concepo: definio do escopo do projeto. Elaborao: elaborao
bsica do software. Construo: desenvolvimento. Transio;
Slide 51
BIBLIOGRAFIA SOUZA, Marcelo souza. UML. Disponvel em:. Acesso
em: 11 de set. de 2013 DESCONHECIDO. Diretrizes: Diagrama de
sequncia. Disponvel em:. Acesso em: 11 de set. de 2013 SAMPAIO,
Marcos Costa,UML. Disponivel em:. Acesso em: 11 de set. de
2013
Slide 52
INFOESCOLA, UML. Disponvel em. Acesso em 11 de set. de 2013
FONSECA, Gabriela, Os principais diagramas da UML- resumo rpido.
Disponivl em. Acesso em 11 de set. de 2013 DESCONHECIDO, Diagramas
de interao. Disponvel em. acesso em 11 de set. de 2013
BIBLIOGRAFIA
Slide 53
FISCHER RUBIRA E SILVA BRITO, Ceclia mary e Patrick Henrique,
Introduo a Anlise Orientada a Objetos e Projeto Arquitetural.
Instituto de computao UNICAMP, campinas-SP.2009. BIBLIOGRAFIA
