Upload
vobao
View
217
Download
1
Embed Size (px)
Citation preview
Marcos Dó[email protected]
Análise e Projeto de SoftwareParte I
Agenda• Apresentação do professor• Apresentação da disciplina• Metodologia e avaliação
Marcos Barbosa Dósea
Apresentação do professor
Currículo� Formação:
– Formado em Ciência da computação– Mestre em Engenharia de Software e Linguagens de
Programação– Certificado Java 5.
� Experiência:– 1 ano como Analista de Sistemas e suporte à Equipe de
Desenvolvimento na Plataforma Java EE na Secretaria de Estado da Fazenda de Sergipe.
– 2 anos na Qualiti Software Processes como consultor na área de arquitetura de software, análise e projeto de sistemas e melhoria e implantação de processos de desenvolvimento de software.
– Consultor na suíte de ferramentas da IBM Rational. – Professor em Disciplinas de Pós-Graduação em Gerência de
Projetos e Engenharia de Software. – Consultor do Centro de Processamento de Dados da
Universidade Federal de Sergipe.– Professor da Universidade Federal de Sergipe.
Contatos• E-mail para atendimento: [email protected]
• Telefone: (79) 9900-2378
Análise e Projeto de Software
Apresentação da disciplina
Característica da disciplina• Nome: Análise e Projeto de Software• Carga horária: 20 horas/aula• Datas: 06/11 e 20/11• Horário: 08:00 às 12:00h e 13:00 às 17:00h• Intervalos: 10:00h e 15:00h (15 minutos)
Objetivo da disciplina
Proporcionar ao aluno um conhecimento amplo das principais técnicas e
ferramentas que podem ser utilizadas para realizar análise e projeto de software Orientado à Objetos.
Ementa• Princípios da Orientação a Objetos. • Classes, Objetos, Encapsulamento, Herança, Agregação e Composição;
• Modelagem Orientada a Objetos. • Diagramas UML. • Análise de Software Orientada a Objetos.• Projeto de Arquitetura de Software• Projeto de Software• Projeto de Banco de Dados• Padrões de desenho (Design Patterns).
Divisão da ementa• PARTE I:
– Diagrama de Classes;– Diagramas de Interação;– Análise e Projeto de Software;
• PARTE II:– Análise de Software Orientado à Objetos;– Projeto da Arquitetura;– Projeto de Software Orientado à Objetos;
Divisão da ementa• PARTE III:
– Arquitetura de Software;– Projeto de Software Orientado à Objetos (continuação)– Projeto de Banco de Dados– Padrões de Projeto Orientado à Objetos
Bibliografia• FILHO, Wilson de Pádua Paula. Engenharia de
Software: Fundamentos, Métodos e Padrões. 2. ed. São Paulo: LTC, 2003.
• SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: Pearson, 2005.
• PRESSMAN, R. S. Engenharia de Software. 5. ed. SãoPaulo: MCGraw-Hill, 2006.
Bibliografia• Rational IBM. RUP (Rational Unified Process).
Disponível em: http://www.wthreex.com/rup/smallprojects/index.htm. Acesso em: 15/09/2009.
• FOWLER, Martin. UML Essencial. 3. ed. São Paulo: Bookman, 2005.
• LARMAN, Craig. Utilizando UML e Padrões. 3. ed. SãoPaulo: Bookman, 2007.
Metodologia e avaliação
Metodologia e avaliação• Aulas expositivas;• Dinâmicas e atividades em grupo;• Os alunos serão avaliados da seguinte forma:– Participação em sala de aula (Presença +
Participação) – 2,0;– Estudo de caso – 8,0;
Cronograma de aulas
Apresentação do trabalhotarde20/118
12 - Padrões de Projetotarde20/117
Estudo de Caso: Projetando o Banco de Dadosmanhã20/116
11 - Projeto de Banco de Dadosmanhã20/116
10 - Projeto de Software OO (continuação)manhã20/116
09 - Arquitetura de Softwaremanhã20/115
Revisãomanhã20/115
Estudo de Caso: Criando modelo de análise e projetotarde6/114
07 - Projeto de Software OOtarde6/114
06 - Projeto da Arquiteturatarde6/114
05 - Análise de Software OOtarde6/113
Estudo de Caso: Criando diagramas de classe e interaçãomanhã6/112
04 - Introdução à Análise e Projeto de Software OOmanhã6/112
03 - Diagrama de Interaçãomanhã6/112
02 - Diagrama de Classesmanhã6/111
01 - Apresentação da Disciplinamanhã6/111
AssuntoTurnoDataAula
Dúvidas
Agenda
• Aula I– Motivação– Diagrama de Classes
Motivação
Marcos Dó[email protected]
O que é análise e projeto?
Qual a importância?
Por onde começar?
• Visão do Sistema
Modelagem de Negócio
Requisitos
Análise
Projeto
Implementação
Por que fazer visualmente?
• Vamos arrumar a estante...
Geografia
História / Inglês Matemática
Física
Física
Estatística Biologia
Diagrama de Classes
Marcos Dó[email protected]
Agenda
• Diagrama de Classes– Características– Classes– Interfaces– Relacionamentos– Esteriótipos– Quando construir?
• Análise• Projeto
Características
• Mais importante e o mais utilizado diagrama da UML.
• Exibe as classes que irão compor o sistema com seus respectivos métodos, atributos e relacionamentos.
• Visão estática da organização das classes.
Características
• Pode ser utilizado para modelar classes persistentes.
• Intencionalmente projetado para ser uma evolução do modelo Entidade-Relacionamento.
Classes
• Podem possuir atributos e métodos.• Não se preocupam com os passos que devem ser percorridos pelos métodos.
• Possui 3 divisões não obrigatórias:– Nome da Classe– Atributos e seus tipos de dados.– Métodos. Cliente
-cpf: long#endereco: String~nome: String
+validar(cpf: long): boolean
Classes
• Visibilidade dos Atributos e Métodos– Privada (-)– Protegida (#)– Pacote (~)– Pública (+) Cliente
-cpf: long#endereco: String~nome: String
+validar(cpf: long): boolean
Cliente
-cpf: long#endereco: String~nome: String-emDebito: boolean = false
+validar(cpf: long): boolean
Classes
• Podemos visualizar ainda...– Tipo dos atributos e argumentos.– Retorno dos métodos.– Valor padrão dos atributos quando criados.
Tipo dos atributos
Tipo dos argumentos
Retorno do método
Valor padrão
Classes
• Atributos e Operações de Instância e Estáticos– A única diferença na representação é queos estáticos ficam sublinhados.
Cliente
-cpf: long#endereco: String~nome: String-emDebito: boolean = false
+validar(cpf: long): boolean
Cliente
-cpf: long#endereco: String~nome: String-emDebito: boolean = false
+validar(cpf: long): boolean
Instância Estático
Classes
• Classe Concreta e Abstrata– Única diferença é o estilo da fonte daclasse abstrata que fica em itálico.
Pessoa Pessoa
Concreta Abstrata
Vamos pensar um pouco...
• Qual seria o melhor nível de visibilidade para os atributos de uma classe?
• Qual o objetivo de uma classe abstrata?
Interfaces
• Duas representações:
FachadaFachada
<<interface>>
Diagrama de Classes
• Relacionamentos– Associações– Especialização / Generalização– Dependência – Realização
Relacionamentos
• Associações– Descreve o vínculo que ocorre entre classes.– Instâncias das classes ligadas às instâncias de outras classes para troca de informações, utilização de métodos, etc.
– São representadas por retas ligando as classes envolvidas.• Navegabilidade não é obrigatória e representa o fluxo das informações.
• É bom dar um nome para associação quando não estiver implícita.
Relacionamentos
• Associações– Multiplicidade
• 0..1 : No mínimo 0 no máximo 1• 1..1 : Um e somente um.• 0..* : No mínimo nenhum e no máximo muitos.• 1..* : No mínimo 1 no máximo muitos.• 3..5: No mínimo 3 no máximo 5.
Relacionamentos
• Associações– Associação Unária ou Reflexiva
Associação
MultiplicidadeMultiplicidade
Papel
Relacionamentos
• Associações– Associação Binária
Relacionamentos
• Associações– Agregação
• Objeto-todo é composto por vários objetos-parte.• Objetos-parte podem existir sem um objeto-todo.• Significado contém, faz parte de, é constituído por
Equipe
Jogador
0. .1
*
A equipe é constuída por n jogadores. Os objetos-parte (jogadores) podem existirsem o objeto-todo (equipe), por isso a multiplicidade do relacionamento 0..1.
Relacionamentos
• Associações– Composição
• É uma agregação com uma restrição mais forte.• Objetos-Parte pertencem exclusivamente a um Objeto-Todo. São criados e destruídos juntos.
Pedido
ItemPedido
*
1 O pedido é constituído por vários itens do pedido. Os objetos-parte (ItemPedido) não podem existir sem o objeto-todo(Pedido), por isso a multiplicidade do relacionamento é 1.
Outros exemplos...
• Qual o tipo de associação existente entre as entidades turma e aluno?
• Qual o tipo de associação existente entre as entidades filme e atores?
Diagrama de Classes
• Relacionamentos– Associações– Especialização / Generalização– Dependência – Realização
Relacionamentos
• Especialização / Generalização– Relação semântica “é um” ou “é uma”.– A subclasse herda atributos e operações dasuper classe, podendo adicionar outras.
Diagrama de Classes
• Relacionamentos– Associações– Especialização / Generalização– Dependência – Realização
Relacionamentos
• Dependência– Objetos de um classe usam serviços de objetos de outra classe.
– Muito úteis para gestão de dependências.
Cliente Servidor
Diagrama de Classes
• Relacionamentos– Associações– Especialização / Generalização– Dependência – Realização
Relacionamentos
• Realização– Um elemento (classe) implementa as operações especificadas por outro elemento (interface). A classe String
implementa a interface
Hashtable
A classe String implementa a
interface Comparable
Classes Associativas
• São classes que estão ligadas a associações, em vez de estarem ligadas a outras classes.
• Também chamadas classes de associação.• Comum entre associações de conectivademuitos para muitos, mas podem aparecer em relacionamentos de qualquer conectividade.
Classes Associativas
• Exemplo
Papel na
associação
Pessoa
+nome+telefone+endereco
Empresa
+razaoSocial+endereco
contrata
+empregador+empregado
**
Emprego
+salario+dataContratacao
Classe associativa
Outros exemplos...
• Como ficaria o relacionamento das entidades Venda e Produto?
• Como ficaria o relacionamento das entidades pessoa e filme?
Esteriótipos
• Mecanismos de extensibilidade da UML.• Bastante utilizado para gerar código.
– Ex: << EJB >>• Nos diagramas de classes podem ser usados nas:– Classes– Métodos– Atributos
Esteriótipos
• Exemplos Esteriótipos de Classes– << file >> : denota o arquivo físico– << library >> : bliblioteca de arquivos.– << table >> : denota uma tabela do banco de dados.
– << thread >>: representa uma thread• Exemplos Esteriótipos de Métodos
– << create >>: cria uma instância da classe.– << destroy >>: destrói uma instância de classe.
Esteriótipos
• Exemplos
Pessoa<<table>>
+nome+telefone+endereco
Pessoa
+nome+telefone+endereco
<<create>>+criar()
Agenda
• Diagrama de Classes– Características– Classes– Interfaces– Relacionamentos– Esteriótipos– Quando construir?
• Análise• Projeto
Visão LógicaVisão Lógica
Quando construir?
Visão de Casos de UsoVisão de Casos de Uso Visão de ProcessosVisão de Processos+
Diagramas de Classes de Projeto
Diagramas de Seqüência
Diagramas de Colaboração
Diagrama de Distribuição
Modelo de Análise e Projeto
Visão de DistribuiçãoVisão de Distribuição+
Diagrama deComponentesModelo de
Casos de Uso
Classes de Análise
• Tipos de Classes de Análise– fronteira ( <<boundary>> )– Controle ( <<control>> )– Entidade ( <<entity>> )
• Estes estereótipos são uma conveniência de análise que desaparecem no projeto
Classes de Análise
• Exemplo:
Conta
login
senha
<<entity>>
TelaLogin
efetuarLogin()
<<boundary>>
CadastroContas
existeCon ta()
<<en tity col lectio n>>
0..n0..n
ControladorLogin
efetuarLogin()
<<control>>
1
0..n
1
0..n
1
1
1
1
Visão LógicaVisão Lógica
Quando construir?
Visão de Casos de UsoVisão de Casos de Uso Visão de ProcessosVisão de Processos+
Diagramas de Classes de Projeto
Diagramas de Seqüência
Diagramas de Colaboração
Diagrama de Distribuição
Modelo de Análise e Projeto
Visão de DistribuiçãoVisão de Distribuição+
Diagrama deComponentesModelo de
Casos de Uso
Perspectivas no Projeto
• Conceitual– Classe interpretada como um conceito.– Apenas classes e atributos são utilizados.
• Especificação– Principais interfaces e métodos.– Prover maior entendimentos da arquitetura.
• Implementação– Especificação é detalhada.– Visibilidades, parâmetros tipos sãoadicionados.
Perspectiva Conceitual
Perspectiva de Especificação
Perspectiva de Implementação
Atividade de Sala I
Crie o diagrama de classes com suas respectivas associações e cardinalidades
contendo as classes que você achar necessário para realizar o caso de uso cadastro de pessoas físicas / jurídicas.
Atividade Sala I
Exercite a criação de diagrama de classes usando o StarUML criando alguns dos diagramas exibidos na apresentação. Exercite a geração do código em
diferentes linguagens.
Agenda
• Aula II– Diagramas de Interação– Introdução à Análise e Projeto de Software
Diagramas de Interação
Marcos Dó[email protected]
Motivação
• Como os diagramas estudados até o momento podem ajudar?– Auxiliam na definição dos requisitos.– Auxiliam o processo de análise do sistema.– Definem classes e responsabilidades.– Definem associações entre classes.
Motivação
• Como determinar a sequência de chamada dos métodos?
• Qual classe inicia o encadeamento daschamadas?
• Todos os métodos necessários já foramdescritos?
• Quais as classes que participam numainteração?
Agenda
• Diagrama de Seqüência– Características– Componentes Básicos
• Diagrama de Comunicação
Diagrama de Seqüência
• Características– Determina a seqüência de eventos que ocorrem num determinado processo.
– Para um mesmo processo (caso de uso) existirão vários diagramas de seqüência.
– Semelhante ao caso de uso especificado.– Os diagramas de sequência e comunicaçãosão chamados diagramas de interação daUML.
Diagrama de Seqüência
• Características– Depende do diagrama de classes e por isso normalmente são construídos em conjunto.
– Concentra-se na seqüência temporal dos eventos.
Diagrama de Seqüência
• Componentes Básicos– Atores– Objetos– Linha de Vida– Foco de Controle ou Ativação– Mensagens ou Estímulos– Condições de guarda– Laços
Diagrama de Seqüência
• Componentes Básicos– Atores– Objetos– Linha de Vida– Foco de Controle ou Ativação– Mensagens ou Estímulos– Condições de guarda– Laços
Diagrama de Seqüência
• Atores– São exatamente os mesmo descritos no caso de uso, ou seja, entidades externas que interagem com o sistema e solicitam serviços.
Diagrama de Seqüência
• Componentes Básicos– Atores– Objetos– Linha de Vida– Foco de Controle ou Ativação– Mensagens ou Estímulos– Condições de guarda– Laços
Diagrama de Seqüência
• Objetos– Representam as instâncias das classes envolvidas no processo.
Representação
através dos dois
pontos (:) seguido do
nome da classe. O
nome do objeto é
opcional.
Diagrama de Seqüência
• Objetos– Quando o objeto existe desde o início o retângulo
aparecerá na parte superior do diagrama. Quando ele écriado no decorrer do processo ele surgirá na mesma altura da mensagem.
Objeto criado após o
início do processo.
Mensagem de criação
do objeto.
Diagrama de Seqüência
• Componentes Básicos– Atores– Objetos– Linha de Vida– Foco de Controle ou Ativação– Mensagens ou Estímulos– Condições de guarda– Laços
Diagrama de Seqüência
• Linha de Vida– Representa o tempo em que um objeto existiu durante um processo. É interrompida com um “X” quando um objeto é destruído.
Linha da vida.
X
Diagrama de Seqüência
• Componentes Básicos– Atores– Objetos– Linha de Vida– Foco de Controle ou Ativação– Mensagens ou Estímulos– Condições de guarda– Laços
Diagrama de Seqüência
• Foco de Controle ou Ativação– Indica os períodos em que um determinado objeto está participando ativamente do processo.
Foco de controle.
Diagrama de Seqüência
• Componentes Básicos– Atores– Objetos– Linha de Vida– Foco de Controle ou Ativação– Mensagens ou Estímulos– Condições de guarda– Laços
Diagrama de Seqüência
• Mensagens ou Estímulos– Demonstram a ocorrência de eventos que normalmente forçam a chamada de um método de algum objeto envolvido no processo.• Ator – Ator• Ator – Objeto• Objeto – Ator• Objeto - Objeto
Diagrama de Seqüência
• Mensagens ou EstímulosMensagem de criação.
Mensagem para objetos que já existem.
Mensagem de retorno.
Método destrutor
Auto-Chamadas ou Auto-delegações.
<destroy>
Diagrama de Seqüência
• Componentes Básicos– Atores– Objetos– Linha de Vida– Foco de Controle ou Ativação– Mensagens ou Estímulos– Condições de guarda– Laços
Diagrama de Seqüência
• Condições de Guarda– Indica que uma mensagem só poderá ser enviada a um objeto se uma condição for verdadeira.
Condição de guarda.
Diagrama de Sequência
• Condicão de Guarda na UML 2.0
Diagrama de Sequência
• Condicional Mutuamente Exclusiva
Diagrama de Seqüência
• Componentes Básicos– Atores– Objetos– Linha de Vida– Foco de Controle ou Ativação– Mensagens ou Estímulos– Condições de guarda– Laços
Diagrama de Sequência
• Loop
Vamos pensar um pouco...
Utilizando as classes criadas para realizar o cadastro de clientes crie o diagrama
de sequência para realizar a operação de inserção e remoção de dados no banco
de dados.
Roteiro
• Diagrama de Seqüência• Diagrama de Comunicação
– Características– Componentes Básicos
Diagrama de Comunicação
• Características– Possui as mesmas funções do diagrama de seqüência.
– Concentra-se na organização estrutural dos objetos.
– É possível gerá-lo a partir do diagrama de seqüência e vice-versa.
Diagrama de Comunicação
• Componentes Básicos– Objetos– Atores– Vínculos– Mensagens– Condições
Diagrama de Comunicação
• Objetos– São as instâncias da classe que participam de um processo.
Semelhante a
representação do
diagrama de seqüência.
Coleção de
dependentes.
Diagrama de Comunicação
• Componentes Básicos– Objetos– Atores– Vínculos– Mensagens– Condições
Diagrama de Comunicação
• Atores– São os mesmos do diagrama de seqüência e conseqüentemente os mesmo do diagrama de casos de uso.
Diagrama de Comunicação
• Componentes Básicos– Objetos– Atores– Vínculos– Mensagens– Condições
Diagrama de Comunicação
• Vínculos– Indicam as ligações que existem entre os objetos envolvidos em um processo, ou seja, os objetos colaboram entre si.
Diagrama de Comunicação
• Componentes Básicos– Objetos– Atores– Vínculos– Mensagens– Condições
Diagrama de Comunicação
• Mensagens– Representam a chamada dos métodos. São as mesmas do diagrama de seqüência.
– Não existem mensagens de retorno.
A seta indica a direção para
onde a mensagem foi
enviada.
Diagrama de Comunicação
• Mensagens– Também é possível disparar uma mensagem para si próprio.
Auto-Chamada.
Diagrama de Comunicação
• Mensagens– Podem ser enviadas diversas vezes.
Mensagem enviada repetidas vezes.
Pode-se restringir o número de vezes.
Ex: *[i := 1..10]
Variável de Retorno
Coleção de objetos
Diagrama de Comunicação
• Componentes Básicos– Objetos– Atores– Vínculos– Mensagens– Condições
Diagrama de Comunicação
• Condições– Mensagem só é enviada se a condição for satisfeita.
Condição.
Diagrama de Comunicação
Atividade Sala II
Crie um projeto no StarUML contendo as classes necessárias para realização de um CRUD para os dados de uma Pessoa. Crie diagramas de interação para definir os métodos necessários nessas classes.
Introdução à Análise e Projeto de Software
Marcos Dó[email protected]
Agenda
• Introdução• Como fazer Análise? • Fluxo de Análise e Projeto do RUP
Introdução
• Onde estamos?
Introdução
• O que faremos?– Analisar o Software– Definir a arquitetura– Projetar o Software
• Componentes• Banco de Dados
Análise x Projeto
Modelo complexo.Modelo simples
Requisitos Funcionais e Não Funcionais
Requisitos Funcionais
Representação próximado código.
Estrutura geral daarquitetura do sistema
Detalha operações e atributos dos objetos
Comportamento caixapreta
Foco na soluçãoFoco no problemaProjetoAnálise
Quais os artefatos produzidos?
Análise e
Projeto
Análise e
Projeto
Modelo de Casos de Uso
Projeto de Banco de Dados
Documento de Requisitos
Glossário
Documento da Arquitetura
Mapeamento das Classes de Análise em Elementos de Projeto
Modelo de Análise e Projeto
Quais os artefatos produzidos?
• O que é produzido?Modelo de Casos de Uso Modelo de Análise e Projeto
Diagrama de Classes
Diagrama de Seqüência
Diagrama de Colaboração
Realização de Caso de Uso
Caso de Uso
Quais os artefatos produzidos?
• Pode ser um modelo que inicia naatividades de análise (visão abstrata) e éconcluído no projeto (visão detalhada).
• Podem ser dois modelos– Modelo de Análise– Modelo de Projeto (evoluído do modelo de análise)
• Como escolher?– Documentação x Esforço Manutenção
Fluxo de Análise e Projeto
Analisar caso de usoProjetista
Projetista de banco de dados
Revisar projeto
Projetar caso de uso
Arquiteto
Revisor do projeto
Projetar base de dados
Projetar arquitetura
Projetar subsistema
Projetar classes