A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Análise do Sistema Alexandre Mota

Apresentações semelhantes


Apresentação em tema: "Análise do Sistema Alexandre Mota"— Transcrição da apresentação:

1 Análise do Sistema Alexandre Mota

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

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

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 > NomeDaClasse + atribPub: Tipo = Inicial # atribProt - atribPriv > new() > getRiscos(o: Cliente) * * pode ser: {persistent}

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

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 GerenteBD Sistema Abre Conta Solicita Info Cliente Info Cliente Fornecida Solicita Tipo de Conta Tipo de Conta Fornecida Solicita Saldo Inicial Saldo Inicial Fornecido Confirmação Cria Conta

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 Exemplo de CRC Class Name Catalog ResponsibilitiesCollaborations Catalog number Remove Book Add Book Book Catalog store { { Atributos Métodos

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

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

22 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 : Estudante Form. Matrícula 1: entra id 2: verifica id 3: entra semestre atual 4: cria novo cronograma 5: processa Form. Matrícula >

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 >

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

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


Carregar ppt "Análise do Sistema Alexandre Mota"

Apresentações semelhantes


Anúncios Google