Anlise Projeto de Software Alexandre Monteiro Desenvolvendo o

Análise & Projeto de Software Alexandre Monteiro

Desenvolvendo o Sistema Documento de Requisitos Problema Solução . . .

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

Uma Abordagem. . . n n 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 n n João, ela, minha conta, o elevador 1 Nomes comuns ou no plural indicam classes ou interfaces n Clientes, contas, um elevador

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

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

Infelizmente. . . n n n 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 n n 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

Granularidade n Casos de uso revelam dois maiores níveis de abstração: n n O visual apresenta os principais métodos do sistema Os fluxos revelam interações entre classes, associações, dependências, herança, etc.

Elementos de Modelagem << Classe. Especial >> Nome. Da. Classe + atrib. Pub: Tipo = Inicial # atrib. Prot - atrib. Priv << constructor>> new() <<query>> get. Riscos(o: Cliente) Responsabilities -- Determina o risco de uma venda * * pode ser: {persistent}

Elementos de Modelagem Pessoa Empresa Trabalha para Pessoa Empregado 1. . * Pessoa Empregado Empresa Empregador Empresa * Empregador Empresa

Elementos de Modelagem Window open() close(). . . handle. Event() Event

Elementos de Modelagem Window open() close(). . . handle. Event() Dialog. Box Console

Elementos de Modelagem Centro 1 * Departamento

Elementos de Modelagem Window 1 * Frame

Elementos de Modelagem Pessoa 1. . * Empregador Função descrição dt. Contrat. . . salário Empresa

Elementos de Modelagem Account. Business. Rules IRule. Agent <<interface>> IRule. Agent add. Rule() change. Rule() Account. Business. Rules

Um Modelo Centro 1. . * tem 1 1. . * Departamento 1. . * eh. Membro * Aluno * 0. . 1 1. . * eh. Associado 1. . * cursa * Disciplina * 1. . * ensina 1. . * chefe 1 Professor

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