prof. msc. emerson silas dória1 análise e projeto orientados a objeto com uml e padrões parte i...
TRANSCRIPT
Prof. Msc. Emerson Silas Dória 1
Análise e Projeto Orientados a Objetocom UML e Padrões
Parte I Introdução
Prof. Msc. Emerson Silas Dória 2
Aplicando UML, Padrões e APOO Objetivo
Desenvolver habilidades práticas em APOO para a criação de sistemas de software bem projetados, robustos e modificáveis.
LPOO são um primeiro passo necessário, mas insuficiente
Outros recursos importantes processo de desenvolvimento padrões UML
Práticas através de estudo de caso detalhado
Prof. Msc. Emerson Silas Dória 3
Atribuindo Responsabilidades Saber a maneira adequada de
atribuir responsabilidades a componentes de software é a habilidade mais importante na APOO Mais difícil de dominar Afeta com mais profundidade a
robustez, modificabilidade e reusabilidade do sistema
Prof. Msc. Emerson Silas Dória 4
Atribuindo Responsabilidades Padrões descrevem princípios
fundamentais para auxiliar na atribuição de responsabilidades, ex: GRASP
Saber identificar objetos ou abstrações adequados é a segunda habilidade mais importante
Prof. Msc. Emerson Silas Dória 5
O que são Análise e Projeto?
Análise — “o quê”
investigação do problema e dos requisitos
Projeto — “como”
descrição de uma solução lógicaQuais os processos de
negócio relacionados com o seu uso?
Como exatamente o software irá capturar e registrar
informações?
Prof. Msc. Emerson Silas Dória 6
Termos “Análise” e “Projeto” não são fixos, mas usados ao longo de um contínuo
Significados variam de metodologia para metodologia
Distinção é útil na prática, mas debater definições rígidas não é construtivo
Conflito de Terminologias
Mais orientado a análise Mais orientado a projeto
Prof. Msc. Emerson Silas Dória 7
O que é APOO?
A essência da APOO é enfatizar a consideração de um domínio de problema e uma solução lógica, segundo a perspectiva de objetos (coisas, conceitos e entidades)
O que é Análise OO? Ênfase na descoberta e na descrição dos objetos.
O que é Projeto OO? Ênfase na definição de elementos lógicos de
software.
Prof. Msc. Emerson Silas Dória 8
Representação de um conceito na APOO
Conceitode domínio
public class Livro{public void imprimir();
private String titulo;}
Representaçãono código
Exemplo: O conceito “Livro” em um sistema de biblioteca.
Livro
título
Representaçãona análise
Livro
título
Representaçãono projeto
imprimir()
Prof. Msc. Emerson Silas Dória 9
Uma analogia — Organizando os negócios de uma empresa
DocumentosAssociados
APOOAnalogia de
Negócio
Casos de usoAnálise de requisitosQuais são os processos de negócio?
Modelo conceitualAnálise do domínioQuais são os papeis dos empregados?
Diagramas de classes de projeto, diagramas de colaboração
Atribuição de responsabilidades, projeto das interações
Quem é responsável por o quê? Como eles interagem?
Prof. Msc. Emerson Silas Dória 10
Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete
Processo de Software OO
Jogo de DadosExemplo
Definir Casos de Uso
Definir ModeloConceitual
Definir Diagramas de Interação
Definir DiagramasClasses de Projeto
Prof. Msc. Emerson Silas Dória 11
Casos de Uso Descrições narrativas de processos do
domínio no formato de prosa estruturada
Jogo de DadosExemplo continuação...
Caso de uso:Atores:Descrição:
JogarJogadorEste caso de uso começa quandoo jogador rola os dados. Se o totaldos dados for sete, o jogador ganha;do contrário, ele perde.
Prof. Emerson Silas Dória - FIPP
12
Modelo Conceitual Conceitos, atributos, e associações
que são considerados importantes no domínio do problema
Jogador
Nome
JogoDeDados
Dado
ValorDaFace
lança
joga
inclui
2
2
1
1
1
1
Jogo de DadosExemplo continuação...
Prof. Msc. Emerson Silas Dória 13
Modelo Conceitual Um modelo conceitual descreve
conceitos do mundo real, não componentes de software!
Jogo de DadosExemplo continuação...
Prof. Msc. Emerson Silas Dória 14
Diagramas de InteraçãoDiagrama de Colaboração Alocação de responsabilidades para objetos e
ilustração de como eles interagem via mensagens
Mostram o fluxo de mensagens entre instâncias e a invocação de métodos
:Jogador d1 : Dado
Jogar( ) 1: r1 := Lançar( )
2: r2 := Lançar( ) d2 : Dado
Jogo de DadosExemplo continuação...
Prof. Msc. Emerson Silas Dória 15
Diagramas de Interação Diagrama de Seqüência
:JogoDeDados
d2:Dadod1:Dado
Lançar( )
vf1:=ObterValorDaFace( )
Lançar( )
vf2:=ObterValorDaFace( )
Jogar()
Jogo de DadosExemplo continuação...
Prof. Msc. Emerson Silas Dória 16
Diagramas de Classes de Projeto Como os objetos (de software) se conectam? Quais são os métodos de uma classe?
2Jogador
Nome
Jogar( )
Dado
Valordaface:int
Lançar( )
1
Versão 1
JogoDeDados
Inicializar( )
12
Jogo de DadosExemplo continuação...
Prof. Msc. Emerson Silas Dória 17
Diagramas de Classes de Projeto Como os objetos (de software) se conectam? Quais são os métodos de uma classe?
Jogo de DadosExemplo continuação...
2JogoDeDados
d1,d2:Dado
Jogar( )
Dado
Valordaface:int
Lançar( )ObterValorDaFace():int
1
Versão 2
Prof. Msc. Emerson Silas Dória 18
APOO X APE
Sistema deBiblioteca
Sistema
A&P Orientados a Objetodecomposição por objetos ou conceitos
A&P Estruturadosdecomposição por funções ou processos
RegistraEmpréstimos
AdicionaRecursos
ReportaMultas
Catálogo
Livro
Bibliotecário
Biblioteca
Metodologias mais antigas, como Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposição
Prof. Msc. Emerson Silas Dória 19
A UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projeto
A notação (a própria UML) é relativamente trivial Muito mais importante: habilidade para modelar
com objetos Só aprender a notação UML não ajuda
A UML não é um processo ou metodologia APOO regras de projeto
A Linguagem de Modelagem Unificada
Prof. Msc. Emerson Silas Dória 20
Origem e Evolução da UML
Unified Method 0.8 Unificação I(Out’95)
Booch’93 OMT-2
Outros métodos Booch’91 OMT-1 OOSE Fragmentação
UML 1.0
Parceirosda UML
Padronização(Jan’97)
UML 1.1 Industrialização(Set’97)
UML 0.9 & 0.91 Unificação II(Out’96)
Prof. Msc. Emerson Silas Dória 21
Processo de Desenvolvimento Um processo de desenvolvimento de
software é um método para organizar as atividades relacionadas à criação, entrega e manutenção de sistemas de software.
A habilidade de saber como criar um bom projeto é mais importante do que seguir um método ou processo oficial.
Prof. Msc. Emerson Silas Dória 22
Processo de Desenvolvimento Essa habilidade é adquirida dominando-se
um conjunto de princípios e heurísticas para identificar e abstrair um conjunto relevante de objetos e atribuir responsabilidade a eles.
Em essência, a descrição de um processo inclui atividades que vão da análise dos requisitos até a instalação.
O material apresentado (e a disciplina) não vão tratar de atividades tais como: concepção, planejamento, gerenciamento, documentação e teste.
Prof. Msc. Emerson Silas Dória 23
Processo de Desenvolvimento UML padroniza artefatos e
notação, mas não define um processo-padrão, razões:
Aumentar a probabilidade de aceitação ampla de uma notação de modelagem padronizada;
Variação significativa naquilo que constitui um processo apropriado;
Prof. Msc. Emerson Silas Dória 24
Processo Iterativo Simplificado Planejar e Elaborar: planejamento,
definição de requisitos, protótipo, etc; Construir: a construção do sistema; Instalar: a colocação em uso do sistema;
planejar
elaborarconstruir
instalar
Prof. Msc. Emerson Silas Dória 25
Desenvolvimento Iterativo Um ciclo de vida iterativo envolve a
repetição de vários ciclos de planejamento, elaboração, construção e instalação.
O sistema cresce pela adição de novas funções (e refinamento das existentes) em cada ciclo iterativo.
Cada ciclo ataca um pequeno conjunto de requisitos.
Prof. Msc. Emerson Silas Dória 26
Desenvolvimento Iterativo
Ciclo deDesenv. 1
Sinc.Artefatos Análise Projeto TesteRefin.
PlanoImpl.
Ciclo deDesenv. 2 ...
ConstruçãoPlan. &Elaboração
Implantação
Prof. Msc. Emerson Silas Dória 27
Casos de Uso e CVIs Um caso de uso é uma descrição textual
(narrativa) de um processo do domínio. Exemplo: “Emprestar um livro da biblioteca”
Os ciclos de desenvolvimento iterativos são organizados com base nos requisitos de um conjunto de casos de uso.
Os casos de uso devem ser classificados e os mais importantes devem ser atacados nos CVIs iniciais, bem como requisitos não funcionais.
Prof. Msc. Emerson Silas Dória 28
CVIs baseados em Casos de Uso
Ciclo de Desenvolvi-
mento 1
Caso de uso AVersãoSimplificada------
Ciclo de Desenvolvi-
mento 2
Caso de uso AVersãoCompleta------
Ciclo de Desenvolvi-
mento 3
Caso de uso B
Caso de uso C
...
Prof. Msc. Emerson Silas Dória 29
Planejar e Elaborar Definir plano inicial Criar Relatório de Investigação Preliminar Definir Requisitos Registrar termos no glossário (a) Implementar protótipo (b,d) Definir casos de uso(alto nível e essenciais) Definir modelo conceitual inicial Definir a arquitetura inicial do
sistema(a,c,d) Refinar o plano
a:permanente
b:opcional
c: pode atrasar
d: qq ordem
Prof. Msc. Emerson Silas Dória 30
Análise Definir os casos de uso essenciais (se
ainda não foi feito) Refinar os diagramas de casos de uso Refinar o modelo conceitual Refinar o glossário (permanente) Refinar os Diagramas de Seqüência do
Sistema Definir os contratos de operação Definir os diagramas de estado (opcional)
Prof. Msc. Emerson Silas Dória 31
Projeto Definir casos de uso reais Definir Relatórios, Interface e Storyboards Refinar a arquitetura do sistema (qq
ordem) Definir diagramas de interação Definir diagramas de classe do projeto (em
paralelo com diagramas de interação) Definir esquema da base de dados
Prof. Msc. Emerson Silas Dória 32
Casos de Uso e CVIs Na fase de planejamento e
elaboração, criar todos os casos de uso de alto nível, mas refinar apenas os mais críticos e importantes, deixando os demais para outros CVIs.
Prof. Msc. Emerson Silas Dória 33
Definição de Modelos e Artefatos O mundo real é complexo e cheio de
detalhes, por isso ele deve ser decomposto em partes, chamadas de modelos, que descrevem e abstraem aspectos essenciais dos sistemas.
Modelos são compostos de outros modelos, que são chamados de artefatos - diagramas e documentos – e são visualizados em visões.
Os modelos podem enfatizar aspectos dinâmicos e estáticos do sistema.
Prof. Msc. Emerson Silas Dória 34
Definição de Modelos e Artefatos
Modelo de Análise: modelos relacionados a uma investigação do domínio e do espaço do problema, mas não à solução.
Modelo de Projeto: modelos relacionados à solução lógica.