Análise e Projeto de Software Parte I · de arquitetura de software, análise e projeto de...

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


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


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


Cliente

-cpf: long#endereco: String~nome: String-emDebito: boolean = false


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



Cliente



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

• 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

• 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

• 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>>


Pessoa


<<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


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


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.


• 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.


• Componentes Básicos– Atores– Objetos– Linha de Vida– Foco de Controle ou Ativação– Mensagens ou Estímulos– Condições de guarda– Laços


• Atores– São exatamente os mesmo descritos no caso de uso, ou seja, entidades externas que interagem com o sistema e solicitam serviços.


• 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.


• 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.


• 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


• Foco de Controle ou Ativação– Indica os períodos em que um determinado objeto está participando ativamente do processo.

Foco de controle.


• 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


• 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>


• 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


• Condicional Mutuamente Exclusiva


• 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.


• Componentes Básicos– Objetos– Atores– Vínculos– Mensagens– Condições


• 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.


• Atores– São os mesmos do diagrama de seqüência e conseqüentemente os mesmo do diagrama de casos de uso.


• Vínculos– Indicam as ligações que existem entre os objetos envolvidos em um processo, ou seja, os objetos colaboram entre si.


• 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.


• Mensagens– Também é possível disparar uma mensagem para si próprio.

Auto-Chamada.


• 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


• Condições– Mensagem só é enviada se a condição for satisfeita.

Condiçã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


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



• O que é produzido?Modelo de Casos de Uso Modelo de Análise e Projeto

Diagrama de Classes


Diagrama de Colaboração

Realização de Caso de Uso

Caso de Uso


• 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

Análise e Projeto de Software Parte I · de arquitetura de software, análise e projeto de...

Documents

Transcript of Análise e Projeto de Software Parte I · de arquitetura de software, análise e projeto de...