280 likes | 391 Views
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
E N D
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 requisitos Detalhes e Dec. de projeto Perspectiva do Desenvolvedor Perspectiva do Usuário
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
Modelo • Para criarmos um modelo do sistema, temos que identificar: • Objetos • Classes • Atributos • Métodos • Associações entre classes • Outros relacionamentos entre classes
Classes << Estereótipo >> NomeDaClasse * * pode ser: {persistent} + atribPub: Tipo = Inicial # atribProt - atribPriv << constructor>> new() <<query>> getRiscos(o: Cliente)
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
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
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
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
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
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
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
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
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”
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
Class Name Catalog Responsibilities Collaborations Catalog number Book Catalog store Add Book Remove Book Exemplo de CRC { Atributos { Métodos
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
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
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
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
<<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
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
Janelas • Protótipos (desenhos) de janelas podem ser criados para representar a classe boundary ao usuário
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
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
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
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
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