POOe UML

Modelagem de Sistemas com UML
Fernando A. Vanini
<vanini@klais.com.br>
www.klais.com.br +55 19 3249-2222
Modelamento de Sistemas e Orientao a Objetos

O paradigma de Orientao a Objetos oferece um conjunto de caractersticas que se bem utilizadas apresentam inmeras vantagens no projeto de um sistama. Tirar proveito dos recursos oferecidos pela Orientao a Objetos exige que se considere o sistema sendo projetado luz dessas caractersticas.
25/3/2009 Modelagem de sistemas com UML - (c) Klais Solues Ltda 2
UML
UML (Unified Modeling Language) uma notao grfica que tem por objetivo o modelamento de sistemas baseados em objetos. Definida por los tres amigos: Booch, Rambaugh e Jacobson. Padronizada pelo OMG (Object Management Group).
Modelagem de sistemas com UML - (c) Klais Solues Ltda
25/3/2009
UML
UML apenas uma notao. Para que o seu uso num projeto seja efetivo necessrio definir um processo ou metodologia de projeto. projeto.
25/3/2009
Modelo
Um modelo uma abstrao da realidade.
Exemplo: mapa de uma cidade

modelo que representa as ruas e como elas se conectam. Atravs de um mapa possvel determinar o caminho para se chegar a um determinado ponto.
O mesmo mapa, no entanto omite detalhes irrelevantes para o uso ao qual se destina. Exemplos:
tipo da pavimentao localizao e altura dos edifcios inclinao do terreno.
Modelagem de sistemas com UML - (c) Klais Solues Ltda 5
25/3/2009
Uso de Modelos em Projetos

Modelos tem sido usados h muito tempo como ferramenta de projeto. Exemplo: Construo civil
maquetes planta baixa planta eltrica planta hidrulica
Cada modelo enfatiza os aspectos importantes para os seus objetivos.
25/3/2009
Uso de Modelos em Projetos

Dependendo do projeto, vrios tipos de modelo podem ser necessrios, cada um enfatizando um conjunto de aspectos do projeto. O uso de vrios modelos necessrio para que se possa descrever toda a complexidade do projeto.
25/3/2009
Modelos e Vises
Ao enfatizar um conjunto de aspectos do sistema, um modelo d uma viso do sistema. A descrio completa do sistema pode exigir vrias vises - da a necessidade de vrios tipos de modelos.
25/3/2009
As vises em UML
As vises so usadas em UML para descrever os diferentes aspectos do sistema sendo modelado. Uma viso uma abstrao do sistema, formada por um conjunto de diagramas. A partir de um conjunto de vises se chega a uma descrio completa do sistema a ser construdo
25/3/2009
As vises em UML
Viso de Casos de Uso - mostra a funcionalidade do sistema do ponto de vista externo. Viso Lgica - descreve a organizao do sistema, seus mdulos principais, como eles se relacionam e suas funcionalidades Viso de Componentes - descreve a arquitetura fsica do sistema, em termos de componentes de software Viso de Implantao mostra a alocao dos componentes de software no equipamento alvo.
25/3/2009
10
Metodologias Tradicionais
Dados e funcionalidades so tratados como elementos independentes. As linguagens e ambientes de programao tradicionais estimulam essa abordagem.
Funcionalidades
Dados
25/3/2009
11
Metodologias Tradicionais
Um exemplo
Funcionrio
nome endereo registro cargo salrio situao data de admisso
Dados descrevem caractersticas estticas do funcionrio. Caractersticas dinmicas (relativas ao negcio) so expressas pelos programas que implementam as funcionalidades
Diferentes aplicaes que utilizem os mesmos dados devem implementar as caractersticas dinmicas da mesma maneira, para que no ocorram inconsistncias.
Objetos
Objetos reunem num nico elemento as caractersticas estticas e comportamentais comportamentais. Caractersticas estticas so representadas como dados associados ao objeto Elas objeto. descrevem o estado atual do objeto. Caractersticas dinmicas so descritas atravs de operaes ou mtodos executados pelo objeto. Estado e comportamento so partes integrantes do objeto.
Objetos
Um exemplo
Estado: dados (ou atributos) que descrevem o estado atual do objeto Comportamento: mtodos que descrevem os aspectos dinmicos do objeto. Funcionrio
nome endereo registro cargo salario_bruto situao data de admisso calcular_salrio_lquido() atualizar_situao() alterar_cargo() calcular_FGTS() verificar_saldo_frias()
25/3/2009
14
Encapsulamento
Um objeto encapsula numa nica entidade o seu estado e os mtodos que definem o seu comportamento. Consequncia
acoplamento mais fraco entre as diversas partes do sistema menor probabilidade de interferncias esprias entre as partes do sistema
Mtodos e mensagens
A execuo de um mtodo disparada pelo envio de uma mensagem ao objeto. A execuo do mtodo a interpretao que o objeto d mensagem.
desenha(azul)
Tringulo origem p1 p2 desenha(cor) pinta(cor)
25/3/2009
16
Mtodos e mensagens
Objetos diferentes podem dar interpretaes diferentes a uma mesma mensagem Tringulo origem
desenha(azul)
p1 p2 desenha(cor) pinta(cor)
desenha(azul)
Retngulo origem largura altura desenha(cor) pinta(cor)
25/3/2009
17
Interface
A interface de um objeto formada pelo conjunto de mensagens tratadas pelo objeto.
As mensagens 'desenha' e 'pinta' constituem a interface de um objeto Retngulo.
25/3/2009
18
Objetos e Classes
Umobjeto um conceito, abstrao ou objeto conceito, algo que tenha um significado bem definido para o problema em questo uma classe descreve um grupo de objetos com o mesmo conjunto de propriedades (atributos), os mesmos relacionamentos com outros objetos e a mesma semntica (operaes ou mtodos)
Um objeto uma instncia (ou um exemplar) de uma classe.
25/3/2009
19
Objetos e Classes
Maria ... Joo ... Ana ... Pedro ...
Todos os objetos da classe funcionrio oferecem a mesma interface e mantm o mesmo conjunto de atributos.
Jos ...
classe Funcionrio
Cada instncia no entanto tem os seus prprios valores para os cada um dos atributos
25/3/2009
20
Classes em UML
nome da classe Retngulo origem largura altura desenha(cor) pinta(cor) atributos (dados)
mtodos
25/3/2009
21
Herana
Uma classe pode dar origem a outras classes atravs de herana (ou especializao). Os objetos da classe derivada herdam da classe origem (ou classe-me) todos os atributos e mtodos. A classe derivada pode estender a classe-me agregando novos atributos e mtodos. Ela pode tambm redefinir mtodos da classeme.
Herana
classe-me
Figura origem desenha(cor) pinta(cor) move(dx,dy)
classederivada
Tringulo origem p1 p2 desenha(cor) pinta(cor)
25/3/2009
generalizao
23
Herana em UML
ou
25/3/2009
24
Hierarquia de Classes
Herana tambm se aplica a classes derivadas de outras isso pode dar origem a uma hierarquia de classes.
25/3/2009
25
Polimorfismo
Numa situao onde se espera um objeto de uma determinada classe C sempre possvel utilizar um objeto de uma classe derivada de C.
desenhar a figura
25/3/2009
26
Os pilares da OO
Encapsulamento, herana e polimorfismo constituem os pilares da orientao a objetos. Encapsulamento
melhora a modularidade do sistema disciplina as interfaces reduz interferncias entre as partes
Herana e polimorfismo
fatorao de elementos comuns favorece o reuso
Objetos e o 'mundo real'

Objetos tm se mostrado convenientes para descrever elementos e situaes do mundo real. real. Por essa razo, quando se usa objetos para modelar um sistema, possvel partir de conceitos pertencentes ao domnio do problema. problema Os detalhes no domnio da soluo podem ser postergados at o momento em que se tenha uma idia clara do que o sistema deve fazer.
Domnio do Problema
Os conceitos no domnio do problema tendem a se manter estveis ao longo da vida do sistema. Exemplo: num sistema de administrao escolar
aluno, sala, turma, professor, disciplina, curso
Um sistema cuja arquitetura modelada com base nesses conceitos tende a suportar melhor a evoluo (necessria em qualquer sistema).
As vises em UML
Viso de Casos de Uso - mostra a funcionalidade do sistema do ponto de vista externo. Viso Lgica - descreve a organizao do sistema, seus mdulos principais, como eles se relacionam e suas funcionalidades Viso de Componentes - descreve a arquitetura fsica do sistema, em termos de componentes de software Viso de Implantao mostra a alocao dos componentes de software no equipamento alvo.
25/3/2009
30
Viso de Casos de Uso

Descreve a funcionalidade que o sistema deve oferecer, do ponto de vista do mundo externo. O mundo externo representado por um conjunto de atores ou atores externos que interagem com o sistema.
Sistema
25/3/2009
31
Viso de Casos de Uso - atores

Exemplo: num sistema de automao comercial, os atores seriam
clientes operadores de caixa operador de crdito computadores do sistema bancrio e administradoras de carto de crdito
ator em UML:
25/3/2009
32

Os casos de uso so levantados a partir da idia de necessidade do sistema, antes mesmo de se pensar numa arquitetura para o mesmo. Eles so a base do processo uma vez que dirigem o desenvolvimento das demais vises.
25/3/2009
33

O objetivo final do sistema oferecer a funcionalidade descrita pelos casos de uso. Sendo assim, a viso dos casos de uso importante tambm na validao do sistema.
25/3/2009
34

Casos de uso podem ser descritos atravs de uma descrio textual, e/ou visualmente atravs dos Diagramas de Casos de Uso.
25/3/2009
35
Descrio do caso de uso

Para cada caso de uso deve conter:
Atores que participam do caso de uso O que caracteriza o incio e o fim do caso de uso A interao do sistema com os atores Quais os dados necessrios sua realizao Sequncia normal de eventos Sequncias alternativas (excees)
Em geral a metodologia de desenvolvimento especifica a estrutura da descrio do caso de uso.
25/3/2009
36
Diagrama de Casos de Uso

Os diagramas de caso de uso tm por objetivo a descrio dos mesmos de forma visual.
25/3/2009
37
Diagrama de Casos de Uso

Relacionamento entre casos de uso
25/3/2009
38
Casos de Uso - exemplo
25/3/2009
39
Casos de Uso
Os diagramas de caso de uso tm por objetivo descrever graficamente as situaes de uso do sistema. Eles podem no ser suficientes para descrever todos os detalhes da situao de uso necessrios s fases subseqentes do projeto. A descrio textual dos casos de uso em geral necessria para descrever esses detalhes.
Viso Lgica
A viso de casos de uso descreve o sistema do ponto de vista do mundo externo a ele. A viso lgica tem por objetivo descrever como a funcionalidade do sistema ser obtida. A viso lgica descreve o sistema do ponto de vista interno. interno.
25/3/2009
41
Viso Lgica
A viso lgica envolve
estrutura esttica do sistema (mdulos, classes, objetos e relacionamentos) aspectos dinmicos (manifestados atravs de mensagens entre objetos, eventos externos, etc).
25/3/2009
42
Viso Lgica
A estrutura esttica descrita atravs de diagramas de classes e diagramas de componentes. componentes. O modelamento dinmico feito atravs de diagramas de sequncia, diagramas de sequncia, colaborao e diagramas de estado. estado.
25/3/2009
43
Relacionamentos entre classes

Num sistema, as classes podem ter diversos tipos de relacionamentos entre si. Herana um dos tipos possveis de relacionamento entre classes. Uma associao o tipo mais comum desses relacionamentos. Uma associao uma conexo bidirecional entre duas classes.
Associao
Um exemplo: supondo que pas e cidade so classes de um sistema, um pas est associado a uma cidade que a sua capital.
25/3/2009
45
Relacionamentos e papis
No relacionamento entre duas classes, cada uma desempenha um papel especfico. Esse papel, sempre que possvel, deve ser explicitado no modelo.
25/3/2009
46
Multiplicidade (cardinalidade)
Numa associao, a participao de cada classe pode ser associada a uma indicao de multiplicidade.
Exemplo: uma disciplina tem um nico professor responsvel e este por sua vez pode ser responsvel por vrias disciplinas.
25/3/2009
47
Associao
Uma classe pode estar envolvida em mais de uma associao.
25/3/2009
48
Dependncia
Uma classe pode fazer uso de outras classes
como tipo de um de seus atributos como tipo de um dos parmetros de seus mtodos na implementao de seus mtodos
25/3/2009
49
Instanciao
Um objeto de uma classe, ao executar seus mtodos pode criar instncias de objetos de outras classes.
25/3/2009
50
Agregao
Descreve o relacionamento da forma parte entre classes. todotodo-
Um pargrafo, no exemplo acima, s faz sentido se pargrafo, estiver agregado a um documento (no existem 'pargrafos soltos'). O mesmo vale para sentena, com relao a pargrafo.
Agregao bi-direcional
A agregao usada nos exemplos anteriores pressupe que a sua implementao bidirecional
No exemplo, um documento consegue identificar os seus pargrafos assim como um pargrafo consegue identificar o documento ao qual pertence.
25/3/2009
52
Agregao uni-direcional
Em muitos casos, durante a modelagem se deseja deixar explcito que a agregao unidirecional.
Neste exemplo, um documento consegue identificar os seus pargrafos mas um pargrafo no capaz de identificar o documento do qual parte.
25/3/2009
53
Agregao - outro exemplo
25/3/2009
54
Diagrama de Classes
25/3/2009
55
Diagrama de Classes - Exemplo
25/3/2009
56
25/3/2009
57
25/3/2009
58
25/3/2009
59
Esteretipos de Classes
UML permite extenses pelo usurio atravs da criao de esteretipos. esteretipos. na maioria dos sistemas algumas classes se encaixam em tres categorias, que podem ser descritas como esteretipos padro: esteretipos padro:
Classes de Entidade Classes de Controle Classes de Interface
25/3/2009
60
Classes de Entidade
Normalmente so identificadas com os principais elementos no domnio do problema.
Exemplo, num sistema de administrao escolar
estudante curso currculo professor disciplina Classes de Entidade, na maioria dos casos, se referem a Entidade, informaes que devem ser mantidas em banco de dados. dados.
25/3/2009
61
Classes de Controle
As Classes de Controle normalmente so responsveis pela coordenao das atividades especificadas nos casos de uso e aparecem como participantes nos Diagramas de Interao. So classes dependentes da aplicao, responsveis pelas regras de negcio envolvidas.
Classes de Interface
As Classes de Interface descrevem as interaes entre o sistema sendo descrito e o mundo exterior. exterior. Tipicamente correspondem s classes responsveis pela interface com o usurio e pela comunicao com outros sistemas.
25/3/2009
63
Diagramas de Interao
Diagramas de Interao mostram, para cada cenrio descrito num caso de uso, as uso, interaes entre os atores e as classes envolvidas Em UML existem dois tipos de Diagramas de Interao: Diagramas de Sequncia e Diagramas de Colaborao. Colaborao.
25/3/2009
64
Diagramas de Sequncia
25/3/2009
65
Diagrama de Sequncia
25/3/2009
66
Diagrama de Colaborao
5: consulta (item,quant.) 8: confirma(item,quant.) 1: cod. cliente 4: item,quant. 7: confirma pedido
Controle de Estoque
Terminal de Atendimento
6: confirma disponib. 2: consulta (cod. cliente) Cadastro de Clientes
3: dados do cliente
25/3/2009
67
Diagramas de Estado
Os cenrios nos Casos de Uso e os Diagramas de Interao descrevem o comportamento do sistema. Em alguns casos necessrio descrever o comportamento interno de um objeto. Isso objeto. feito atravs dos Diagramas de Estado. Estado.
25/3/2009
68
Diagramas de Estado
Os principais elementos de um diagrama de estado so
estados (possveis) transies ( indicam mudanas de estado do objeto) eventos externos (provocam a mudana de estado no objeto) estado inicial estado final
25/3/2009
69
Diagrama de Estados
Criao da disciplina Professor se inscreve Aguardando professor Professor desiste Aguardando programao Inicio das aulas
incio cancelamento
cancelamento
Encerramento Em curso Estado final
25/3/2009
70
Diagrama de Estados
25/3/2009
71
Diagrama de Estados
25/3/2009
72
Diagrama de Atividades
Um diagrama de estados descreve as mudanas de estado de um objeto, em funo de eventos externos. Em muitas situaes, os objetos interagem entre si e as mudanas de estado de um objeto dependem de aes executadas por outro objeto. O diagrama de atividades permite descrever as operaes associadas a um objeto e tambm as interaes com outros objetos (concorrncia).
Diagrama de Atividades
25/3/2009
74
Diagrama de Componentes
25/3/2009
75
Diagrama de Componentes
25/3/2009
76
Diagrama de Implantao
25/3/2009
77
Na prtica ...
UML apenas uma notao - para que seja eficaz num projeto necessrio que o seu uso ocorra sob um processo bem definido. O objetivo final do projeto (em geral) o software rodando adequadamente na casa do cliente.
25/3/2009
78
Na prtica ...
Qualquer que seja o processo de desenvolvimento, o ponto de partida natural para um projeto que use UML so os diagramas de caso de uso. No existe, no entanto uma receita mgica para, partindo dos casos de uso, se chegar aos demais diagramas.
25/3/2009
79
Na prtica ...
Nem todos os recursos da notao UML so necessrios num projeto:
diagramas de estado ou de atividades nem sempre so usados. diagramas de classe e diagramas de seqncia quase sempre so necessrios. alguns tipos de relacionamentos podem no aparecer num diagrama de classe. a metodologia utilizada pode enfatizar o uso de determinados recursos ou se basear em esteretipos pr-definidos.
Na prtica ...
Os modelos em UML podem ser to detalhados quanto se queira:
medida que se desce em detalhes, aumenta o comprometimento da implementao com o modelo. Para que os modelos faam sentido para a equipe de programao, o projetista deve conhecer os recursos oferecidos pelo ambiente de desenvolvimento at o nvel de detalhe que ele vai usar nos modelos.
Uma abordagem iterativa

1. Levantamento dos casos de uso e elaborao dos respectivos diagramas. 2. A partir dos casos de uso, procurar identificar as principais partes (mdulos, pacotes ou componentes do sistema). 3. Com base no particionamento e nos casos de uso, elaborar os diagramas de seqncia correspondentes. 4. Com base nos diagramas de seqncia, em geral possvel refinar o particionamento.
25/3/2009
82

5. Tendo refinado o particionamento, os diagramas de seqncia podem ser refinados. Neste ponto, j se tem idia se sero necessrios novos diagramas de seqncia, de estado ou de atividades. 6. Os dois passos anteriores devem ser repetidos at que os detalhes levantados sejam suficientes para se iniciar a fase de construo do sistema. 7. Os diagramas de componentes e implantao podem ser elaborados a partir da finalizao do passo anterior.
25/3/2009
83

A abordagem sugerida subjetiva e depende da experincia e bom senso do projetista. Sua aplicabilidade depende do processo de desenvolvimento sendo utilizado.
25/3/2009
84
Referncias
The Unified Modeling Language User Guide, G. Booch, J. Rambaugh, Ivar Jacobson, Addison-Wesley, 1999 Applying Use Case Modeling with UML, D. Rosenberg, K. Scott, Addison-Wesley, 2001 UML in a Nutshell, S.S.Alhir, O'Reilly, 1998 Visual Modeling with Rational Rose and UML, T. Quatrani, AddisonWesley, 2000
Referncias na web:
UML Tutorial, http://www.sparxsystems.com.au/UML_Tutorial.htm http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/
Unified Modeling Language Tutorial,
25/3/2009
85
Impacto no Ciclo de Vida do Software

Pelo fato de encapsular estado e comportamento, objetos so adequados a representar conceitos ou elementos do mundo real. Como os requisitos evoluem ao longo do processo de desenvolvimento, a realimentao por parte do cliente final nesse perodo importante e em geral influencia o sistema sendo desenvolvido. Metodologias que prevem esse tipo de realimentao, baseadas em variantes da espiral evolutiva acabam sendo mais adequadas para o desenvolvimento de sistemas baseados em objetos.
86
Impacto no Ciclo de Vida do Software

As caractersticas impostas arquitetura, principalmente baixo acoplamento e reuso influenciam a fase de verificao e validao do sistema. Pelas mesmas razes, a evoluo do sistema tambm afetada.
87
Impacto na Arquitetura do Software

baixo acoplamento: objetos, pelas sua caracterstica de encapsulamento, permitem que se modele a arquitetura do sistema a partir de elementos com baixo acoplamento entre si. As partes do sistema que usam um dado objeto, no precisam saber como ele funciona, precisam saber apenas quais os servios que ele oferece (expresso pelos mtodos que ele exporta). reuso: herana e polimorfismo estimulam a reutilizao do cdigo que implementa as classes. O baixo acoplamento entre as parte por sua vez facilita o reuso.
88
Impacto na Arquitetura do Software

foco no domnio do problema ao invs de domnio da soluo. componentes de software: objetos tm sido usados para a criao de componentes de software, que alm de oferecerem mtodos para acesso aos seus servios, oferecem mtodos adicionais que permitem o seu registro, identificao e caracterizao dos seus servios.
89
Impacto nas Ferramentas de Desenvolvimento

ambientes de desenvolvimento: novos ambientes disponibilizam ao projetista um conjunto de componentes que podem ser facilmente integrados s aplicaes. extensibilidade: novos componentes podem, desenvolvidos por terceiros ou pela prpria equipe, podem ser integrados ao ambiente de desenvolvimento, abrindo um leque de infinitas possibilidades.
90
Impacto nas Ferramentas de Desenvolvimento

Integrao IDE-CASE: atualmente, a maior parte dos IDEs (integrated development environment) est se integrando com ferramentas CASE (computer aided software engineering), de forma que modelamento e desenvolvimento andam juntos, de forma integrada.
91
Impacto na Equipe de Desenvolvimento

a partir do domnio de bibliotecas e ferramentas de desenvolvimento, o programador passa a ser uma pea importante no processo de desenvolvimento. A definio da arquitetura, por ser influenciada pelo uso dos objetos, pelo reuso e pela farta disponibilidade de componentes, na maioria dos casos, necessita da participao do programador-arquiteto.
92
Impacto na Equipe de Desenvolvimento

o programador por sua vez, necessita cada vez mais dominar todo o contexto formado pelos recursos de programao oferecidos pela linguagem e ambiente sendo utilizados, assim como bibliotecas de classes, componentes e mdulos de software candidatos ao reuso.
93
Componentes
componente de software: um objeto que alm de oferecer mtodos para acesso aos seus servios, oferece mtodos adicionais que permitem o seu registro, identificao e caracterizao dos seus servios. um componente para operar como tal, necessita de um suporte do ambiente operacional que permita o seu registro, sua identificao e identificao de seus servios. o ambiente operacional que d suporte aos componentes pode ser o prprio sistema operacional, ou mesmo uma biblioteca.
94
Toolkits (bibliotecas de classes)

Conjunto de classes reutilizveis projetadas para oferecer um funcionalidades voltadas para uma rea de aplicao especfica. Toolkits enfatizam o reuso de cdigo sem impor nenhuma caracterstica estrutural arquitetura.
95
Frameworks
Um framework um conjunto de classes cooperantes voltado ao desenvolvimento de aplicaes numa determinada rea. A construo de uma aplicao se d a partir da construo de classes abstratas definidas no framework. O framework estabelece a arquitetura da aplicao.
96
Mtodo Estruturado e Processos baseados em UML/OO

Estruturado Diagrama de Contexto DFD Depsito de Dados Processo Diagrama Estrutural Dicionrio de Dados Descrio dos processos DTE ??? UML/OO Casos de Uso Diagramas de Sequncia Diagrama de Sequncia Classes de entidade Mtodos/mensagens Diagrama de Classes ?? ?? Diagrama de Transio Diagrama de Atividades UML: indica apenas as interaes entre objetos Diagrama estrutural: no indica os relacionamentos. DFD: nenhuma idia de tempo e sequenciamento. Obs.

POOe UML

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

POOe UML

Diunggah oleh

Hak Cipta:

Format Tersedia

Modelagem de Sistemas com UML

www.klais.com.br +55 19 3249-2222

Modelamento de Sistemas e Orientao a Objetos

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Exemplo: mapa de uma cidade

Uso de Modelos em Projetos

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Uso de Modelos em Projetos

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

nome endereo registro cargo salrio situao data de admisso

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Tringulo origem p1 p2 desenha(cor) pinta(cor)

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Retngulo origem largura altura desenha(cor) pinta(cor)

Modelagem de sistemas com UML - (c) Klais Solues Ltda

As mensagens 'desenha' e 'pinta' constituem a interface de um objeto Retngulo.

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Um objeto uma instncia (ou um exemplar) de uma classe.

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Tringulo origem p1 p2 desenha(cor) pinta(cor)

Retngulo origem largura altura desenha(cor) pinta(cor)

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Objetos e o 'mundo real'

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Viso de Casos de Uso

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Viso de Casos de Uso - atores

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Viso de Casos de Uso

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Viso de Casos de Uso

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Viso de Casos de Uso

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Descrio do caso de uso

Em geral a metodologia de desenvolvimento especifica a estrutura da descrio do caso de uso.

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Diagrama de Casos de Uso

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Diagrama de Casos de Uso

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Casos de Uso - exemplo

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Relacionamentos entre classes

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda

Modelagem de sistemas com UML - (c) Klais Solues Ltda