1 / 28

Análise do Sistema

Análise do Sistema. Alexandre Mota (acm@cin.ufpe.br). Form. Matrícula. : Estudante. 1: entra id. 2: verifica id. 3: entra semestre atual. 4: cria novo cronograma. 5: processa. Desenvolvendo o Sistema. Sub-sistemas. Documento de Requisitos. Problema. Solução. Modelo dos

masao
Download Presentation

Análise do Sistema

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Análise do Sistema Alexandre Mota (acm@cin.ufpe.br)

  2. Form. Matrícula : Estudante 1: entra id 2: verifica id 3: entra semestre atual 4: cria novo cronograma 5: processa Desenvolvendo o Sistema Sub-sistemas Documento de Requisitos Problema Solução ... Modelo dos requisitos Detalhes e Dec. de projeto Perspectiva do Desenvolvedor Perspectiva do Usuário

  3. Modelo UML: “Visão 4+1” Funcionalidade Configuração Logical View Development View Class diagrams, Sequence diagrams Component diagrams Use Cases/ Scenarios Use Case diagrams, Sequence diagrams Process View Physical View Deployment diagrams Deployment diagrams Topologia Performance

  4. Modelo • Para criarmos um modelo do sistema, temos que identificar: • Objetos • Classes • Atributos • Métodos • Associações entre classes • Outros relacionamentos entre classes

  5. Classes << Estereótipo >> NomeDaClasse * * pode ser: {persistent} + atribPub: Tipo = Inicial # atribProt - atribPriv << constructor>> new() <<query>> getRiscos(o: Cliente)

  6. Semântica das Classes • A descrição da classe deve • Focar em seu propósito (funcionalidade) e não em sua implementação • Na análise, as classes só devem estar relacionadas ao domínio do problema Essência é “O QUÊ” e não “COMO” Análise Projeto

  7. Abordagem 1: Linguagem • Para identificar objetos, classes e interfaces, liste todos os nomes (substantivos), pronomes e frases do seu documento de requisitos/casos de uso • Nomes próprios e frases que indiquem unicidade representam objetos • João, ela, minha conta, o elevador 1 • Nomes comuns ou no plural indicam classes ou interfaces • Clientes, contas, um elevador

  8. Abordagem 1: Linguagem • Para identificar serviços (métodos), atente para os verbos ou frases verbais • Clientes podem depositar na poupança • Para identificar atributos, analise as frases que expressam propriedades de objetos/classes • Clientes possuem uma senha, ou A senha do cliente deve ser de no mínimo 8 caracteres

  9. Abordagem 1: Linguagem • Verbos também podem identificar associações entre objetos, classes ou interfaces • Uma disciplina tem pelo menos 3 alunos matriculados • Assim como, relacionamentos de herança, dependência, etc. • Uma poupança é um tipo especial de conta bancária

  10. Infelizmente... • Na documentação informal, existirão nomes que não serão objetos, classes e nem interfaces • Não há um algoritmo que nos permita modelar um sistema da forma perfeita • Tudo depende de experiência e julgamentos corretos na hora de escolher o grau de abstração certo

  11. Utilidade dos casos de uso • Casos de uso são mais interessantes que texto informal pois são mais estruturados e orientados a serviços • Casos de uso naturalmente são vistos como métodos • As intenções de um subconjunto de casos de uso revelam as classes • Demais elementos são obtidos pelos fluxos de ações ou diag. de seqüência

  12. Diagrama de Seqüências Sistema Gerente BD Abre Conta Solicita Info Cliente Info Cliente Fornecida Solicita Tipo de Conta Tipo de Conta Fornecida Solicita Saldo Inicial Saldo Inicial Fornecido Cria Conta Confirmação

  13. Abordagem 2: Cartões CRC • CRC vem de Class-Responsibility-Collaboration • Um cartão CRC mostra • Nome da classe e descrição • Suas responsabilidades • Conhecimento interno (atributos) • Seus serviços (métodos) • Os colaboradores das responsabilidades • Um colaborador é uma classe cujos serviços são necessitados por uma responsabilidade

  14. Uma sessão CRC • Grupo de pessoas desenvolvem um cenário • Um cartão é criado para cada objeto no cenário • Cada participante é associado a grupo de cartões • A pessoa torna-se a “classe”

  15. Uma sessão CRC • Os cenários definidos são praticados pelos participantes • Os cartões são anotados com as responsabilidades e colaborações • Novos cartões surgem para novos objetos descobertos

  16. Class Name Catalog Responsibilities Collaborations Catalog number Book Catalog store Add Book Remove Book Exemplo de CRC { Atributos { Métodos

  17. Class Name Catalog Responsibilities Collaborations Catalog number Book Catalog store Add Book Remove Book Atualizações { Atributos { Métodos Diagrama de Classes + Diagrama de Seqüências

  18. Evolução • Trabalho vai bem se . . . • Todas as classes têm nomes significativos, domínio específico e pequeno conjunto de colaboradores • Não há classes “instáveis” (uma classe que colabora com alguém precisa ser re-definida completamente) • Mudança nos requisitos só envolve classes

  19. Evolução • E mal se . . . • Várias classes não têm responsabilidades • Mesma responsabilidade atribuída a várias classes • Todas as classes colaboram com todas as outras classes

  20. Estereótipos (<< >>) • Um estereótipo representa a classificação de uma classe • Toda classe deve ter apenas um estereótipo • Mais comuns • Boundary, Entity, Control, Exception, Utility

  21. <<boundary>> Class Name Boundary • Classe boundary modela a comunicação entre a parte interna e externa do sistema • Mais comuns • Windows (GUI) • Protocolo de comunicação (interface do sistema) • Interface com a impressora • Sensores

  22. Form. Matrícula : Estudante 1: entra id 2: verifica id 3: entra semestre atual <<boundary>> 4: cria novo cronograma Form. Matrícula 5: processa Boundary • Informações entre ator e sistema devem estar contidas em classe boundary • Diagramas de seqüência são examinados para identificar o conteúdo da classe

  23. Janelas • Protótipos (desenhos) de janelas podem ser criados para representar a classe boundary ao usuário

  24. Interface com outros Sistemas • Classe boundary também pode ser usada para modelar interface com outros sistemas • Suas características são: • Informação a ser comunicada com o outro sistema • Protocolo de comunicação usado nesta transferência

  25. Entidade • Classe de entidade modela informação geralmente “persistente” • Valores de seus atributos são freqüentemente fornecidos por um ator • Exemplos seriam • Curso • Estudante • Professor • Conta <<entity>> Conta

  26. Diagrama de Seqüência • Os diagramas de seqüência são atualizados • Classes adicionais são incluídas no diagrama • Objetos no diagrama são associados a classes

  27. 6: display 7: select course 8: process 10: get prerequisite 11: prerequisite taken ? 12: add student (John) Diagrama Atualizado :Registration :Schedule :Catalogue :Course :Student :Course :Schedule :Billing System :Registration John : Form Form Manager Record Roster Student 1: enter id 2: validate id 3: enter current 4: create new 5: display 9: create schedule 13: print 14: send to billing system 15: registration complete 16: registration complete

  28. Bibliografia • Sommerville, I. Software Engineering • Kruchten, P. The Rational Unified Process: An Introduction • Tepfenhart, W. et al. Practical Object-Oriented Development with UML and Java

More Related