Get documents about "Princ�pios da Orienta��o a Objetos Ling
Document Sample
Márcia Moita Machado
Princípios da Orientação a Objetos
Linguagem de Modelagem Unificada
UML
Márcia Moita Machado
UML
A Unified Modeling Language (UML) é uma linguagem
de modelagem não proprietária de terceira geração.
A UML não é uma metodologia de desenvolvimento,
não mostrando como projetar seu sistema, e sim
auxiliando a visualização de seu desenho e a
comunicação entre objetos.
É uma notação independente de processos, embora o
RUP (Rational Unified Process) tenha sido
especificamente desenvolvido utilizando a UML.
Márcia Moita Machado
Histórico
• Os esforços para a criação da UML tiveram início em
outubro de 1994, quando Rumbaugh se juntou a
Booch na Rational.
• Com o objetivo de unificar os métodos Booch e OMT,
decorrido um ano de trabalho, foi lançado, em outubro
de 1995, o esboço da versão 0.8 do Unified Process -
Processo Unificado (como era conhecido).
• Nesta mesma época, Jacobson se associou à Rational
e o escopo do projeto da UML foi expandido para
incorporar o método OOSE. Nasceu então, em junho
de 1996, a versão 0.9 da UML.
Márcia Moita Machado
Evolução da UML
O Object Management
Group (OMG) é uma
organização internacional
que aprova padrões
abertos para aplicações
orientadas a objetos.
A OMG possibilitou que
outras empresas
pudessem contribuir com
a evolução da UML, daí
se chegou à versão 1.1.
Após alcançar essa versão, a OMG passou a adotá-la como padrão e a
se responsabilizar pelas revisões, que são controladas a não provocar
uma grande mudança no escopo original, para não haver grande
impacto, o que facilitou sua disseminação pelo mundo.
Márcia Moita Machado
Visões Arquiteturais
Alguns sistemas de software são complexos, por isso é conveniente
visualizá-los de formas diferentes. Daí surge o conceito de visões de
software, que estão ligadas à modelagem do sistema.
Márcia Moita Machado
Visões UML 2
Visão Descreve Diagramas
Visão de Requisitos funcionais diagramas de casos de
Requisitos do sistema pelo ponto uso
Funcionais de vista do usuário.
Visão Estrutural Estrutura estática do diagrama de classes
Estática sistema. diagrama de estruturas
Visão de Comportamento diagramas de seqüências
Comportamento dinâmico do sistema, diagramas de atividades
Dinâmico mostrando suas diagramas de estados
interações.
Márcia Moita Machado
Diagramas
Representação gráfica parcial ou total de um modelo.
A UML 2.0 define 13 tipos de diagramas divididos em 2 categorias:
- Diagramas Estruturais - Diagramas Comportamentais
• Pacotes • Casos de uso
• Classes • Atividades
• Objetos • Máquina de estado
• Estrutura Composta • Colaboração ou Comunicação
• Componentes • Seqüência
• Instalação • Tempo
• Interatividade
Márcia Moita Machado
MODELAGEM ESTÁTICA OU ESTRUTURAL
• Diagramas estáticos ou estruturais definem
estaticamente a arquitetura de um modelo.
• São usados para modelar classes, objetos, relações e
componentes físicos que compõem um modelo.
• Além disso, também são usados modelar os
relacionamentos e as dependências entre elementos.
Márcia Moita Machado
DIAGRAMA DE PACOTES
• O Diagrama de pacotes ou diagrama de módulos
descreve os pacotes ou pedaços do sistema divididos
em agrupamentos lógicos, mostrando as interações
entre eles em alto nível (já que pacotes podem
depender de outros pacotes).
• Esse diagrama é muito utilizado para ilustrar a
arquitetura de um sistema mostrando o agrupamento
de suas classes.
Márcia Moita Machado
DIAGRAMA DE PACOTES
Interface
gráfica
Regras de
negócio
Acesso ao
Banco de Dados
Márcia Moita Machado
DIAGRAMA DE CLASSES
• Define os elementos básicos de um modelo, ou seja,
os tipos, as classes e os relacionamentos usados para
construir um modelo completo.
• Em programação, um diagrama de classes é uma
representação da estrutura e relações das classes que
servem de modelo para objetos.
• É uma modelagem muito útil para o sistema,
definindo todas as classes que o sistema necessita
possuir e é a base para a construção dos diagramas
de comunicação, seqüência e estados.
Márcia Moita Machado
DIAGRAMA DE OBJETOS
• É uma variação do diagrama de classes e utiliza quase a
mesma notação, com duas exceções: os objetos são
escritos com seus nomes sublinhados e todas as
instâncias num relacionamento são mostradas.
• A diferença é que o diagrama de objetos apresenta os
atributos com valores e mostra os objetos que foram
instanciados das classes. É como se fosse o perfil do
sistema em um certo momento de sua execução.
• Os diagramas de objetos não são tão importantes como
os diagramas de classes, mas eles são muito úteis para
exemplificar diagramas complexos de classes ajudando
muito em sua compreensão.
• Também são usados como parte dos diagramas de
colaboração, onde a colaboração dinâmica entre os
objetos do sistema é mostrada.
Márcia Moita Machado
DIAGRAMAS DE CLASSES E DE OBJETOS
Curso Aluno
Professor
ministra -codDisciplina: String
-matrícula: String * -matrícula: String
[1..3] [1..5] -descrição: String [0..10] -nome: String
-nome: String -codTurma: String -período: Integer
p1: Prof essor
p2: Prof essor
matricula: "205-6712-09"
nome: "Jaelson Castro"
c1: Curso c3: Curso
: Curso c2: Curso
: Curso
codCurso: "IF291"
codCurso: "IF185"
descrição: "MPS" : Aluno
descrição: "AER" : Aluno
codTurma: I7
codTurma: I6
: Aluno
: Aluno : Aluno :aluno
Bill Lew insky
matricula: "219846534"
:aluno nome: "Nelson Mandella"
: Aluno
matricula: "562746134"
nome: "John Major"
Márcia Moita Machado
DIAGRAMA DE ESTRUTURA COMPOSTA
• Definido a partir da UML 2.0 e do RUP.
• Destina-se à descrição dos relacionamentos entre os
elementos, ou seja, a colaboração interna de classes,
interfaces ou componentes para especificar uma
funcionalidade.
• Fornece meios de definir a estrutura de um elemento e
de focalizá-la no detalhe, na construção e em
relacionamentos internos, mostrando a estrutura interna
(incluindo partes e conectores) de um classificador
estruturado ou colaboração.
Márcia Moita Machado
DIAGRAMA DE ESTRUTURA COMPOSTA
Márcia Moita Machado
DIAGRAMA DE COMPONENTES
• Ilustra como as classes deverão se encontrar, organizadas
através da noção de componentes de trabalho, ou seja,
apresenta as dependências ente componentes de software,
incluindo implementação de classes, arquivos de código fonte,
arquivo de código binário, arquivos executáveis, scripts.
• Utilizado para:
* Modelar os componentes do código-fonte, do código executável do
software;
* Destacar a função de cada módulo para facilitar a sua reutilização;
* Auxiliar no processo de engenharia reversa, por meio da
organização dos módulos do sistema e seus relacionamentos.
Componente: Peça física distribuível e substituível de código que contém
elementos que apresentam um conjunto de interfaces requeridas e fornecidas.
Márcia Moita Machado
DIAGRAMA DE COMPONENTES - EXEMPLO
Márcia Moita Machado
DIAGRAMA DE COMPONENTES – EXEMPLO UML 2.0
Márcia Moita Machado
DIAGRAMA DE INSTALAÇÃO OU EXECUÇÃO
• Mostra a configuração dos elementos de processamento em
tempo de execução, além dos componentes, processos e
objetos do sistema neles existentes, sendo usado para
modelar a arquitetura de um sistema de informação da
perspectiva dos seus componentes físicos/hardware
(computadores, adaptadores de rede, impressoras, routers
etc), explicitando as suas dependências de comunicação,
assim como, que componentes são instaladas em cada nó
computacional, ilustrando a configuração dos elementos de
processamento e dos componentes de software, processos e
objetos neles suportados. Modela também sistemas cliente-
servidor e sistemas distribuídos.
Márcia Moita Machado
DIAGRAMA DE INSTALAÇÃO
Márcia Moita Machado
MODELAGEM DINÂMICA (DE COMPORTAMENTO)
• Os diagramas dinâmicos ou de comportamento
apresentam as variedades da interação e do estado
instantâneo dentro de um modelo enquanto é
“executado”.
Márcia Moita Machado
DIAGRAMA DE CASOS DE USO
• Descreve a funcionalidade proposta para o novo sistema,
sendo usado para modelar interações do usuário/sistema.
• Define o comportamento, as exigências e o resultado
esperado de uma funcionalidade.
• Segundo Ivar Jacobson, idealizador do modelo, pode-se
dizer que um Caso de Uso é um "documento narrativo que
descreve a seqüência de eventos de um ator que usa um
sistema para completar um processo".
• Um Caso de Uso pode "usar" outra funcionalidade de Caso
de Uso ou "estender" outro Caso de Uso com seu próprio
comportamento.
Márcia Moita Machado
DIAGRAMA DE CASOS DE USO
<<estende>>
info pagamento
info entrega
Comprar produto Prover
Pontos de extensão informações
info pagamento
info entrega
RELAÇÕES
Checar
senha
<<usa>>
Encaminhar
Compra
GENERALIZAÇÃO
<<usa>>
Validar Scannear
usuário retina
Márcia Moita Machado
DIAGRAMA DE MÁQUINA DE ESTADOS
• Em engenharia de software e eletrônica digital, um
diagrama de transição de estados é uma representação do
estado ou situação em que um objeto pode se encontrar no
decorrer da execução de processos de um sistema.
• Com isso, o objeto pode passar de um estado A (estado
inicial) para um estado B (estado final) através de uma
transição.
• Representa as ações ocorridas em reposta ao recebimento
de um evento, onde cada ponto de parada representa um
estado da aplicação.
Márcia Moita Machado
DIAGRAMA DE MÁQUINA DE ESTADOS
Registro
Adicionar aluno / Setar Adicionar aluno [Contador < 10]
Inicializado contador = 0
do: Inicializar curso
Open
Aberto
[Contador = 10] Relatório
Cancelado
Curso.Criar relatório
do: Enviar nota cancelamento Cancelar curso
Fechado
Closed
entry: Finalizar curso
entry: Finalize course H
exit: ^CourseRoster.Create roster
exit: Relação Curso.Criar relação
Márcia Moita Machado
DIAGRAMA DE ATIVIDADES
• É uma variação do diagrama de máquina de estados que
representa a execução das ações e as transições que são
acionadas pela conclusão de outras ações ou atividades, ou
seja, um gráfico de fluxo, mostrando o fluxo de controle de
uma atividade para outra.
• Comumente, isso envolve a modelagem das etapas
seqüenciais em um processo computacional.
• Os diagramas de atividade não são importantes somente
para a modelagem de aspectos dinâmicos de um sistema ou
um fluxograma, mas também para a construção de sistemas
executáveis por meio de engenharia de produção reversa.
Márcia Moita Machado
DIAGRAMA DE ATIVIDADES
SWIMLANE
Pessoa Funcionário Pessoa
ELSE
INÍCIO [sem café] [sem Coca]
Procurar bebida
SINCRONIZAÇÃO
(FORK) [achou café] DECISÃO
[achou Coca]
Colocar café Adicionar água Pegar
no filtro à máquina xícara Pegar lata
de Coca
CONDIÇÃO
FLUXO DE AÇÃO Colocar filtro
na máquina
JUNÇÃO (JOIN)
Ligar máquina
Filtrar café
FIM
Colocar café H
Beber
na xícara
Márcia Moita Machado
DIAGRAMA DE COLABORAÇÃO OU COMUNICAÇÃO
• Mostra, de maneira semelhante ao diagrama de seqüência,
a colaboração dinâmica entre os objetos, ou seja, exibe uma
interação, consistindo de um conjunto de objetos e seus
relacionamentos, incluindo as mensagens que podem ser
trocadas entre eles.
• Se a ênfase do diagrama for o decorrer do tempo, o ideal é
o diagrama de seqüência, mas se a ênfase for o contexto do
sistema, a prioridade será o diagrama de colaboração que
dá ênfase à ordenação estrutural em que as mensagens são
trocadas entre os objetos de um sistema.
Márcia Moita Machado
DIAGRAMA DE COLABORAÇÃO OU COMUNICAÇÃO
Márcia Moita Machado
DIAGRAMA DE SEQÜÊNCIA DE MENSAGENS
• Representa a seqüência de processos (mais especificamente
de mensagens passadas entre objetos) num programa de
computador. É usado para representar o comportamento
das operações, métodos (procedimentos ou funções) entre
classes de um cenário.
• Ele registra o comportamento de um único caso de uso
(interações entre objetos de um cenário, realizadas através
de operações ou métodos (procedimentos ou funções)).
Exibe os objetos e as mensagens passadas entre esses
objetos no caso de uso, descrevendo a maneira como os
grupos de objetos colaboram em algum comportamento ao
longo do tempo.
• O diagrama de seqüência dá ênfase à ordenação temporal
em que as mensagens são trocadas entre os objetos de um
sistema. Entende-se por mensagens os serviços solicitados
de um objeto a outro, e as respostas desenvolvidas para as
solicitações.
Márcia Moita Machado
DIAGRAMA DE SEQÜÊNCIA DE MENSAGENS
Márcia Moita Machado
DIAGRAMA DE TEMPO OU TEMPORAL
• O Diagrama de tempo (Timing Diagram), incluído a partir
da UML 2.0, apresenta o comportamento dos objetos e sua
interação em uma escala de tempo, focalizando as
condições que mudam no decorrer desse período.
• Modo alternativo de mostrar um diagrama de seqüência, ou
melhor, a fusão dos diagramas de seqüência e de estado,
apresentando o estado dos objetos em relação ao tempo e
as mensagens que modificam esse estado, usando para isso
métrica de tempo na linha de vida.
• Pode ser útil em aplicações de tempo real.
Márcia Moita Machado
DIAGRAMA DE TEMPO (EXEMPLO)
Márcia Moita Machado
DIAGRAMA DE INTERATIVIDADE
• Diagramas de interatividade são variações de "Diagrama de
atividades", ou melhor, a fusão do diagrama de atividades e
seqüência. Ele permite que fragmentos das interações
sejam facilmente combinados aos pontos e fluxos de
decisão.
Nele, seqüências formam um fluxo de atividades,
mostrando como elas trabalham em uma seqüência de
eventos.
Márcia Moita Machado
DIAGRAMA DE VISÃO GERAL DE INTERAÇÃO
• Uma variação do diagrama de atividade que incorpora
fragmentos de diagrama de seqüencia junto com
construções de fluxo de controle.
Márcia Moita Machado
COMPARAÇÃO ENTRE OS DIAGRAMAS DA 1ª E 2ª VERSÕES
Márcia Moita Machado
Estudo de Caso
Márcia Moita Machado
Estudo de Caso
Considerações sobre o que o sistema se propõe a fazer:
O sistema suportará um cadastro de clientes, onde cada cliente
cadastrado poderá ter várias contas correntes, vários
dependentes ligados a ele, e várias contas de poupança.
Cada dependente poderá possuir várias contas de poupança,
mas não poderá ter uma conta corrente própria.
Entendemos poupança como uma conta que possui um valor,
um prazo de aplicação a uma taxa de juros (definida no
vencimento da poupança).
Entendemos Aplicações Pré-fixadas como uma aplicação de um
valor, em um prazo pré-determinado a uma taxa de juros
previamente definida.
Tanto a conta-corrente quanto a poupança deverão manter um
histórico de todas as movimentações de crédito, débito,
transferências e aplicações de pré-fixados (pré-fixados apenas
para conta corrente).
Uma conta corrente poderá ter várias aplicações pré-fixadas
ligadas a ela.
Márcia Moita Machado
Fases do Desenvolvimento
Análise de Requisitos: Modelar o diagrama de casos de uso do
sistema.
O sistema implementará funções básicas que serão desempenhadas
pela Administração do banco e pelos seus clientes. As principais
funções do sistema são:
Cadastrar novo cliente
Excluir ou editar cliente
Cadastrar dependente
Excluir ou editar dependente
Abrir conta corrente
Fechar conta corrente
Abrir poupança
Fechar poupança
Movimentar conta corrente
Aplicar em pré-fixados
Consultar histórico de conta corrente ou poupança
Cadastrar Agência
Excluir ou Editar Agência
Márcia Moita Machado
Diagrama de Casos de Uso
Representa uma sucessão particular de transações entre o
sistema e um ator (um usuário final ou um sistema externo
ao sistema analisado).
Permite definir todos os modos nos quais os usuários
interagem com a aplicação a ser construída.
Márcia Moita Machado
Diagrama de Casos de Uso
Remover ou
Cadastrar Atualizar Cliente
Cliente Cadastrar
Cadastrar
Dependente
Cliente
Abrir Conta
Corrente
Remover ou
Atualizar
Dependente
Fechar Conta
Corrente
Cadastrar
Operação
Administração (Histórico)
do Banco
Abrir
Poupança
Remover ou
Atualizar Operação
(Histórico)
Fechar
Poupança
Remover ou
Atualizar
Cadastrar
Agência
Agência
Márcia Moita Machado
Diagrama de Casos de Uso
<<usa>> Gerar
Movimentar
Conta Corrente Histórico
<<usa>>
Consultar Aplicar em pré-
Histórico de fixados
Conta Corrente
Cliente
Márcia Moita Machado
Diagrama de Casos de Uso
Manter
Dependente
Manter
Agência
Movimentar
Conta Corrente
Cliente Manter
Cliente
Administração
Consultar <<usa>> do Banco
Histórico de
Conta Corrente
Manter
Operação
(Histórico) Manter Conta
Aplicar em pré- Corrente
fixados <<usa>>
<<estende>>
Manter
Poupança
Márcia Moita Machado
Fases do Desenvolvimento
Análise: Modelar o diagrama de classes.
Na fase de análise, tendo em mãos o diagrama de use-case, podemos
definir o diagrama de classes do sistema.
Este primeiro diagrama da fase de análise deverá ser totalmente
despreocupado de qualquer tipo de técnica relacionada à
implementação do sistema, ou seja, métodos e atributos de acesso a
banco de dados, estrutura de mensagens entre objetos, etc não
deverão aparecer nesse primeiro diagrama, apenas os tipos de objetos
básicos do sistema.
Márcia Moita Machado
Diagrama de Classes
O Diagrama de Classes é uma estrutura lógica que permite o
desenvolvimento das Classes do Sistema.
Para cada Classe desenvolvida no diagrama é possível
especificar seus atributos e operações, assim como o
relacionamento com as demais classes do sistema.
Márcia Moita Machado
Diagrama de Classes
Agência
Cod_Agencia:Caracter Histórico
Nome_Agencia: Caracter
Data: Data
Criar ( ) Operação: Operação
Destruir ( ) Valor: Numérico
Criar ( )
1 Destruir ( )
Possui
* *
Possui Gera
* 1 1
Conta Corrente
Operação
Cod: Caracter
Saldo: Numérico Cod_Agencia:Caracter
Vetor_Aplic_PreFix: Aplic_Pre_Fixadas Nome_Agencia: Caracter
Vetor_Historico: Historico Criar ( )
Agência: Caracter Destruir ( )
Criar ( )
Destruir ( )
Depositar ( )
Debitar ( ) Aplicações Pré Fixadas
Transferir ( ) 0
* Valor: Numérico
Obter_Saldo ( )
Aplicar_Prefix ( ) Data_Venc: Data
Tirar_Extrato ( ) Taxa: Numérico
Retirar_Aplic_Prefix ( )
Criar ( )
Destruir ( )
Márcia Moita Machado
Diagrama de Classes
*
Conta Corrente
1
Possui
Cliente
Cod: Caracter
Saldo: Numérico
Vetor_Aplic_PreFix: Aplic_Pre_Fixadas
Poupança Vetor_Historico: Historico
Agência: Caracter
Possui
Data_Venc: Data Criar ( )
Criar ( ) * Destruir ( )
Destruir ( ) Localizar ( )
1
Abrir_Conta_Corrente ( )
Remover_Conta_Corrente ( )
*
Adic_Dependente ( )
Excluir_Dependente ( )
Possui Abrir_Poupança ( )
1 Fechar_Poupança ( )
Dependente Possui 1
Nome: Caracter
CPF: Numérico *
Parentesco: Caracter
Vetor_Poupanças: Poupança
Criar ( )
Destruir ( )
Localizar ( )
Abrir_Poupança ( )
Fechar_Poupança ( )
Márcia Moita Machado
Diagrama de Objetos
Diagrama de Classes
Conta Aplicações
Cliente
possui Cod: Caracter Cod_Conta: Caracter
Cod: Caracter Saldo: Numérico Nome_Aplicação: Caracter
Saldo: Numérico * Agência: Agência *
cl1: Cliente
cl2: Cliente
Diagrama de Objetos Código: "205-6712-09"
Saldo: 100
c1: Conta c3: Conta
: Conta : Conta c2: Conta
Cod: “Cc2310 Cod: “Cc205"
Saldo: 50 Saldo: 30 :Aplicação
:Aplicação
Agência: Central Agência: Rio Bco
:Aplicação
:Aplicação :Aplicação
:aplicação
FdoFix
CurtoPrazo
:aplicação Cod_Conta: 205
Nome_Aplicação: Fdo
:Aplicação
Cod_Conta: Cc2310
Nome_Aplicação: Fix
Márcia Moita Machado
Fases do Desenvolvimento
Análise: Modelar os diagramas de interação.
Já tendo em mãos as funções primordiais do sistema (diagrama de
casos de uso) e o diagrama de classes da análise do domínio do
problema, partiremos agora para traçar como estas classes irão
interagir para realizar as funções do sistema.
Nesta fase nenhum tipo de técnica de implementação deve ser
considerada.
Para modelar como os objetos do sistema irão interagir entre si,
utiliza-se o diagrama de seqüência ou o de colaboração.
E modela-se um diagrama para cada função (caso de uso) definida no
diagrama de casos de uso.
Escolhe-se o diagrama de seqüência para dar mais ênfase à ordem
cronológica das interações entre os objetos.
Já se faz necessário utilizar idéias básicas da modelagem da interface
do sistema como as janelas. Mas esses objetos de interface serão
totalmente detalhados na fase de design.
Márcia Moita Machado
Diagrama de Seqüência
Um Diagrama de Seqüência mostra interações de objetos
organizadas em uma seqüência de tempo e de mensagens
trocadas, auxiliando na elaboração dos cenários,
implementando a seqüência dos eventos entre os atores e
objetos do Sistema.
Márcia Moita Machado
Diagrama de Seqüência
:Janela Abrir :Conta Corrente :Histórico
Administração :Cliente
Conta Corrente
do Banco
1: Dados do Cliente()
2: Localizar (Caracter)
3: Criar (Cliente)
4: Criar (Operação)
Márcia Moita Machado
Diagrama de Colaboração
Um Diagrama de Colaboração dá ênfase às relações
estruturais entre os objetos.
Márcia Moita Machado
Diagrama de Colaboração
Administração
do Banco
Janela
1: Dados do Cliente()
2: Localizar (Caracter)
Cliente
3:Criar (Cliente)
4: Criar (Operação)
Conta Histórico
Corrente
Márcia Moita Machado
Fases do Desenvolvimento
Análise: Modelar outros diagramas utilizados na UML para a
modelagem dos aspectos dinâmicos do sistema (diagramas de
atividades e de estados).
Nesta fase, modela-se também o diagrama de estados das classes.
Mas este se enquadra em situações onde o comportamento dos objetos
é importante para aplicação.
Por exemplo, em casos de modelagens de sistemas para equipamentos
mecânicos.
Márcia Moita Machado
Diagrama de Estados
A idéia básica do Diagrama de Estado, é estudar certos tipos
de lógicas que envolvem transições possíveis entre diferentes
estados.
Um Diagrama de Estados descreve os possíveis estados de
uma classe e os eventos que causam transições dos estados.
São úteis para mostrar o ciclo de vida de uma classe.
Márcia Moita Machado
Diagrama de Estados
Objeto: Conta Corrente
Criada Adicionar Conta a Cliente Associada a Cliente
Closed
entry: Finalize course
entrada: Atualizar Cliente
saída: Emitir nº Conta
Remover conta
Fechada
fazer: Enviar msg Fechamento
Márcia Moita Machado
Diagrama de Atividades
A principal utilização do Diagrama de Atividades é para
modelar fluxos de procedimentos (workflow), onde existe o
trabalho cooperativo.
Márcia Moita Machado
Diagrama de Atividades
Cliente Administração do Banco
Solicitar abertura
conta
Abrir
conta
Associar cliente a
conta
Movimentar
conta [Solicitação_encerramento=Sim]
Encerrar
conta
H
Márcia Moita Machado
Fases do Desenvolvimento
Design: Complementar modelos da Análise.
Nesta fase, começa-se a implementar nos modelos os melhoramentos
e técnicas de como realmente cada função do sistema será concebida.
Serão modelos mais detalhados com ênfase nas soluções para
armazenamento dos dados, funções primordiais do sistema e interface
com o usuário.
A fase de design pode ser dividida em outras duas subfases:
Design da arquitetura: design de alto nível, onde os pacotes
(subsistemas) são definidos, incluindo as dependências e mecanismos
de comunicação entre eles. Naturalmente, o objetivo é criar uma
arquitetura simples e clara, onde as dependências sejam poucas e que
possam ser bidirecionais, sempre que possível.
Design detalhado: Esta parte detalha o conteúdo dos pacotes. Então
todas classes serão totalmente descritas para mostrar especificações
claras para o programador que irá gerar o código da classe.
Modelos dinâmicos do UML são usados para demonstrar como os
objetos se comportam em diferentes situações.
Márcia Moita Machado
Diagrama de Pacotes
Interface do Usuário
Objetos do Sistema Utilitários
Banco de Dados
Márcia Moita Machado
Modelos da Análise de Requisitos (Domínio do Problema)
Diagramas
...
detalhados
Cliente Conta Poupança
1 * ... ... ...
no Projeto
Conceitos do domínio
Modelos da Análise
:Sistema
Processo de :Caixa Processo
Abertura de Conta NovoCliente() Abertura
1.Cliente chega Evts sistema Caixa
Classes 2.Caixa cadastra Entrar dados ()
conceituais 3.Gerente cria ...
inspiram conta ...
nomes de Diagrama de Casos de Uso
algumas Cenário
classes no Diagrama de Seqüência do Sistema
Projeto
Realização do Modelos do Projeto
Caso de Uso com
Diagramas de :Abertura :Rel de Contas
Interação
CriarNovaConta() AssociarCliente()
:ContaCliente
entraDados(CPF,tpcta)
adicionarDados(CPF,tpcta)
...
Classes
Abertura descobertas
Relação de Contas
no Projeto
... 1 * ... podem ser
resumidas
criarNovaCta()
ObterEspecificação(...):EspecificaçaoCta em
entrarDados(...) ...
... Diagrama de
Classes
Márcia Moita Machado
Fases do Desenvolvimento
Design: Desenhar a arquitetura do sistema.
Nesta fase, serão modelados os diagramas de arquitetura do sistema,
onde o sistema será detalhado em relação aos seus componentes e à
localização física destes.
Márcia Moita Machado
Diagrama de Componentes
Cadastro.exe
sisconta.hlp sisconta.dll
Autenticacao.exe
sisconta.ini
Márcia Moita Machado
Diagrama de Implantação
Pentium IV
Browser
servidorWeb
Autenticação.exe
servidorDeArquivos
Cadastro.exe
O SGBD
servidorBancoDeDados
será
relacional
SGBD
Márcia Moita Machado
Fases do Desenvolvimento
Implementação:
A fase de construção ou implementação é quando as classes são
codificadas.
Os requisitos especificam que o sistema deve ser capaz de rodar em
diversos tipo de processadores e sistemas operacionais.
Uma boa linguagem a ser escolhida é o Java.
Márcia Moita Machado
Fases do Desenvolvimento
Testes:
Nesta fase, a aplicação deverá ser testada.
Deve-se verificar se o programa suporta toda a funcionalidade que lhe
foi especificada na fase de análise de requisitos com o diagrama de
casos de uso.
A aplicação também deve ser testada da forma mais informal,
colocando-se o sistema nas mãos dos usuários.
