© Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte I Análise, Projeto, e Processo.

Apresentação em tema: "© Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte I Análise, Projeto, e Processo."— Transcrição da apresentação:

1 © Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte I Análise, Projeto, e Processo

2 © Nabor C. Mendonça 2001 2 Aplicando UML, Padrões e APOO n Objetivo – Desenvolver habilidades práticas na utilização da TO para a criação de sistemas de software bem projetados, robustos, e modificáveis n Linguagens OO são um primeiro passo necessário mas insuficiente n Outros recursos importantes – processo de desenvolvimento – padrões – UML n Ilustrados na prática através de um estudo de caso detalhado

3 © Nabor C. Mendonça 2001 3 Atribuindo Responsabilidades n Saber a maneira adequada de atribuir responsabilidades a componentes de software é a habilidade mais importante na APOO – Mais difícil de dominar – Afeta com mais profundidade a robustez, modificabilidade e reusabilidade do sistema n Padrões GRASP descrevem princípios fundamentais para auxiliar na atribuição de responsabilidades n Saber identificar objetos ou abstrações adequados é a segunda habilidade mais importante

4 © Nabor C. Mendonça 2001 4 O que é Análise e Projeto? Análise o quê Investigação do problema e dos requisitos Requisitos Casos de uso Restrições Vocabulário Projeto como Descrição de uma solução lógica Objetos Arquitetura Instalação & Operação Interface do usuário

5 © Nabor C. Mendonça 2001 5 n Termos Análise e Projeto não são fixos, mas usados ao longo de um contínuo n Significados variam de metodologia para metodologia n Distinção é útil na prática, mas debater definições rígidas não é construtivo Conflito de Terminologias Mais orientado a análise Mais orientado a projeto

6 © Nabor C. Mendonça 2001 6 O que é APOO? n Na essência, considerar um problema e uma solução dentro da perspectiva de objetos, coisas ou conceitos n O que é AOO? – Investigação dos objetos de domínio e seus relacionamentos Descritos no Modelo de Objetos de Domínio n O que é POO? – Elaboração de uma solução lógica em termos de componentes de software e suas colaborações e responsabilidades Descritos em Diagramas de Classes e Diagramas de Interação

7 © Nabor C. Mendonça 2001 7 Representação de um Conceito na APOO Conceito de domínio public class Livro { public void imprimir(); private String titulo; } Representação no código n Ex.: O conceito Livro em um sistema de biblioteca Livro título Representação na análise Livro título Representação no projeto imprimir()

8 © Nabor C. Mendonça 2001 8 Uma Analogia Organizando os Negócios de uma Empresa Documentos Associados APOOAnalogia Casos de usoAnálise de requisitosQuais são os processos de negócio? Modelo conceitualAnálise do domínioQuais são os papeis dos empregados? Diagramas de classes de projeto, diagramas de colaboração Atribuição de responsabilidades, projeto das interações Quem é responsável por o quê? Como eles interagem?

9 © Nabor C. Mendonça 2001 9 n Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete n Modelagem na APOO – Casos de uso Descrições narrativas de processos do domínio no formato de prosa estruturada Ex.: Um Exemplo Jogo de Dados Caso de uso: Atores: Descrição: Jogar Jogador Este caso de uso começa quando o jogador rola os dados. Se o total dos dados for sete, o jogador ganha; do contrário, ele perde.

10 © Nabor C. Mendonça 2001 10 n Modelagem na APOO (cont.) – Modelo conceitual Conceitos, atributos, e associações que são considerados importantes no domínio da aplicação Ex.: – Um modelo conceitual descreve conceitos do mundo real, não componentes de software! Um Exemplo Jogo de Dados Jogador nome JogoDeDados Dado valor Rola Joga Inclui 2 2 1 1 1 1

11 © Nabor C. Mendonça 2001 11 Um Exemplo Jogo de Dados n Modelagem na APOO (cont.) – Diagramas de colaboração Alocação de responsabilidades para objetos ilustrando como eles interagem via mensagens Mostram o fluxo de mensagens entre instâncias e a invocação de métodos Ex.: :Jogador d1 : Dado d2 : Dado joga() 1: r1 := rola() 2: r2 := rola()

12 © Nabor C. Mendonça 2001 12 n Modelagem na APOO (cont.) – Diagramas de classes de projeto Como os objetos (de software) se conectam? Quais são os métodos de uma classe? Ex.: Rola Joga Inclui 2 2 Jogador nome joga() Dado valor rola() JogoDeDados inicializa() 1 1 1 1 Um Exemplo Jogo de Dados

13 © Nabor C. Mendonça 2001 13 APOO X APE Sistema de Biblioteca Sistema A&P Orientados a Objeto Decomposição por objetos ou conceitos A&P Estruturados Decomposição por funções ou processos Registra Empréstimos Adiciona Recursos Reporta Multas Catálogo Livro Bibliotecário Biblioteca n Metodologias mais antigas, como Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposição

14 © Nabor C. Mendonça 2001 14 n A UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projeto n A notação (a própria UML) é relativamente trivial n Muito mais importante: habilidade para modelar com objetos – Só aprender a notação UML não ajuda n A UML não é – um processo ou metodologia – APOO – regras de projeto A Linguagem de Modelagem Unificada UML

15 © Nabor C. Mendonça 2001 15 Origem e Evolução da UML Unified Method 0.8 Unificação I (Out95) Booch93 OMT-2 Outros métodos Booch91 OMT-1 OOSE Fragmentação UML 1.0 Parceiros da UML Padronização (Jan97) UML 1.1 Industrialização (Set97) UML 0.9 & 0.91 Unificação II (Out96)

16 © Nabor C. Mendonça 2001 16 Processo de Desenvolvimento n Organização das atividades relacionas à produção e manutenção de sistemas de software n Útil, mas um fator de segunda ordem – O principal: equipe qualificada n Boa equipe + bom processo = menor risco n O processo racional unificado (RUP), baseado no modelo iterativo, é o processo padrão na indústria

17 © Nabor C. Mendonça 2001 17 n Simplificação do processo iterativo unificado n Fácil extensão e customização n Não inclui atividades importantes como – Verificação & validação – Divisão do trabalho – Gerência de projeto – Documentação Um Processo Iterativo Simplificado Construção Plan. & Elaboração Implantação

18 © Nabor C. Mendonça 2001 18 Fases n Planejamento e Elaboração – Concepção inicial, investigação de alternativas, definição de requisitos, etc. n Construção – Construção do sistema através de múltiplos ciclos de análise, projeto, implementação e teste n Implantação – Instalação e operação do sistema

19 © Nabor C. Mendonça 2001 19 Modelos e Artefatos n Um modelo descreve e abstrai aspectos essenciais de um sistema – Modelo estático (estrutura) – Modelo dinâmico (comportamento) n Modelos são compostos por artefatos diagramas e documentos que descrevem os elementos do modelo n Na APOO, a UML é usada para descrever e visualizar os modelos e artefatos produzidos em cada fase do processo de desenvolvimento

20 © Nabor C. Mendonça 2001 20 Fase de Planejamento e Elaboração 2. Criar Rel. Prel. de Investigação 3. Definir Requisitos 9. Refinar Plano 7. Definir Mod. Conc. Inicial c 4. Reg. Termos no Glossário a 6. Definir Casos de Uso 1. Definir Plano Inicial 5. Implementar Protótipo b, d a. contínua b. opcional c. adiável d. ordem variada 8. Definir Arquit. Inicial a, c, d Notas Construção Plan. & Elaboração Implantação

21 © Nabor C. Mendonça 2001 21 Fase de Planejamento e Elaboração n Atividades: 1. Definir plano inicial Prazos, recursos, orçamento 2. Criar relatório preliminar de investigação Motivação, alternativas, necessidades de negócio 3. Definir requisitos Especificação declarativa dos requisitos 4. Registrar termos no glossário Dicionário de termos, regras, restrições 5. Implementar protótipo Protótipo do sistema para ajudar na definição dos requisitos

22 © Nabor C. Mendonça 2001 22 Fase de Planejamento e Elaboração n Atividades: 6. Definir casos de uso Descrição em prosa estruturada dos processos de negócio 7. Definir modelo conceitual inicial Objetos de domínio e seus relacionamentos 8. Definir arquitetura inicial Principais subsistemas e suas dependências 9. Refinar plano n Atividades não lineares – Ex.: 7, 4, 6 em paralelo

23 © Nabor C. Mendonça 2001 23 Fase de Construção Ciclo de Desenv. 1 Sinc. Artefatos AnáliseProjetoTeste Refin. Plano Impl. Ciclo de Desenv. 2... Construção Plan. & Elaboração Implantação

24 © Nabor C. Mendonça 2001 24 Fase de Construção n Repetição de ciclos de desenvolvimento – Construção progressiva do sistema até atingir uma versão que satisfaça corretamente os requisitos n Atividades típicas de cada ciclo: 1. Refinar plano 2. Sincronizar artefatos 3. Análise 4. Projeto 5. Implementação 6. Teste

25 © Nabor C. Mendonça 2001 25 Ciclos de Desenvolvimento n Cada ciclo implementa um conjunto reduzido de requisitos, adicionando novas funções ao sistema – Crescimento incremental, através de expansões e refinamentos sucessivos n Ciclos com tempo fixo de duas a oito semanas n Vantagens: – Evita complexidade excessiva – Antecipa feedback dos usuários

26 © Nabor C. Mendonça 2001 26 Ciclos de Desenvolvimento e Casos de Uso n Um ciclo deve atacar um ou mais casos de uso, ou versões simplificadas de casos de uso n Casos de uso mais relevantes devem ser atacados nos primeiros ciclos – Prioridade para serviços com grande influência na arquitetura do sistema ou de alto risco Ciclo de Desenv. 1 Caso de uso A Versão Simplificada Ciclo de Desenv. 2 Caso de uso A Versão Completa Ciclo de Desenv. 3 Caso de uso B Caso de uso C

27 © Nabor C. Mendonça 2001 27 Análise a. se ainda não feito b. contínuo c. opcional 2. Refinar Diag. Casos de Uso 3. Refinar Modelo Conceitual 4. Refinar Glossário b 6. Definir Contrat. de Operação 1. Definir Casos de Uso Essenciais a 5. Definir Diag. Seq. 7. Definir Diag. Estado c Notas... Ciclo de Desenv. 1 Sinc. Artefatos AnáliseProjetoTeste Refin. Plano Impl. Ciclo de Desenv. 2

28 © Nabor C. Mendonça 2001 28 Análise n Subatividades: 1. Definir casos de uso essenciais 2. Refinar diagramas de casos de uso 3. Refinar modelo conceitual 4. Refinar glossário 5. Definir diagramas de seqüência do sistema 6. Definir contratos de operação 7. Definir diagramas de estado

29 © Nabor C. Mendonça 2001 29 Projeto 2. Definir Rel. & IU 4. Definir Diag. Interação 5. Definir Diag. Classes a 6. Definir Esquema do BD 1. Definir Casos de Uso Reais 3. Refinar Arquitetura b Notas a. em paralelo com diag. interação b. ordem variada... Ciclo de Desenv. 1 Sinc. Artefatos AnáliseProjetoTeste Refin. Plano Impl. Ciclo de Desenv. 2

30 © Nabor C. Mendonça 2001 30 Projeto n Subatividades: 1. Definir casos de uso reais 2. Definir relatórios e interfaces com o usuário 3. Refinar arquitetura do sistema 4. Definir diagramas de interação 5. Definir diagramas de classes de projeto 6. Definir esquema do banco de dados