Orientação por Objectos > Modelo de Processo OO > Identificação de Classe e Objectos Aula 12

Sumário Conceitos e Princípios OO Modelo de Processo OO relevantes para o processo de desenvolvimento de SW Modelo de Processo OO Exemplo de Processos dentro de uma Empresa Modelo Recursivo / Paralelo Identificação de Classes e Objectos Análise Sintáctica Gramatical Formas de Manifestação Considerações que um Analista deve ter em mente Boas Práticas para o desenvolvimento de SW OO A engenharia de software é uma derivação da engenharia de sistemas. A engenharia de sistemas em vez de focar só o software, foca-se em diversos elementos. É uma ciência altamente disciplinar

Conceitos e Princípios OO Quem define os objectos? o Engenheiro de Software O que implica a definição de objectos? a descrição de: Propriedades (atributos) Comportamentos (Operações, Serviços ou Métodos) Mensagens Por que é importante? porque os componentes de SW derivados do paradgma OO mostram características associadas com SW de alta qualidade Independência Funcional, Ocultação de Informação, etc.

Conceitos e Princípios OO Quais são os passos? AOO, DOO, Implementação e Testes Qual é o produto obtido? produz-se um conjunto de Modelos Orientados por Objectos ou Diagramas, ou bonecos ;) Estes diagramas descrevem o(s): Requisitos (Documento de Especificação) Desenho Código Processos de Testes … para o desenvolvimento de um Sistema ou Produto OO

Conceitos e Princípios OO Análise Orientada por Objectos Especificação, Casos de Utilização, Diagrama de Classes e de Objectos Identificam-se as Classes e Objectos relevantes no Domínio do Problema Desenho OO Diagramas de Interacção, de Actividades e de Estados aqui descrevem-se detalhes sobre a arquitectura, as interfaces e os componentes a implementação “transforma” o Desenho em Código Testes OO os testes corroboram a arquitectura, as interfaces e os componentes O software OO é mais fácil de manter porque sua estrutura é pouco acoplada – o que implica menos efeitos colaterais quando se fazem mudanças

Casos de Desenvolvimento de SW Variante do modelo iterativo e incremental. Proposto por B. Boehm como resposta as críticas sobre a falta dos outros processos evolutivos na utilização de prototipos e reutilização de software. Permite a construção rápida de aplicações em versões incrementais. Durante as primeiras iterações, a versão incremental poderia ser um modelo em papel o um prototipo. Durante as últimas iterações, se produzem versões cada vez mais acabadas. O modelo em espiral se divide num número de actividades de enquadramento do trabalho, denominadas por regiões de tarefas. Geralmente, existem entre 3 e seis regiões. A figura representa um modelo em espiral que contem 6 regiões: Comunicação com o cliente: estabelecimento de comunicação entre o responsável pelo desenvolvimento e o cliente Planeamento: definição de recursos, tempo e outras informações relacionadas Análise de riscos: avaliação de riscos técnicos e de gestão Engenharia: construção de uma ou mais representações da aplicação Construção e acção: construção, teste, instalação e suporte ao utilizador (treino, documentação e prática) Avaliação do cliente: avaliação da reacção do cliente das representações do software criadas na etapa da engenharia e implementada na etapa de construção e acção Cada das regiões estão compostas por um conjunto de tarefas que se adaptam as características do projecto. Para projectos pequenos o número e formalidade das tarefas é baixo. Em projectos maiores, cada região terá uma série de tarefas definidas para atingir um nível mais alto de formalidade. Em todos os casos se realizam actividades de gestão da configuração e controlo da qualidade

Modelo de Processo OO (ou Modelo Recursivo-Paralelo) Nenhum dos outros modelos vistos pôde ser utilizado isoladamente com sucesso para a OO Modelo de Processo OO (ou Modelo Recursivo-Paralelo) Identificar classes candidatas recursivo (modelo evolutivo) paralelo (reutilização de componentes) buscar classes na biblioteca extrair classes, se existem desenvolver novas classes, se não existem adicionar novas classes à biblioteca construir n-ésima iteração do sistema Análise de Riscos Engenharia e Construção Variante do modelo iterativo e incremental. Proposto por B. Boehm como resposta as críticas sobre a falta dos outros processos evolutivos na utilização de prototipos e reutilização de software. Permite a construção rápida de aplicações em versões incrementais. Durante as primeiras iterações, a versão incremental poderia ser um modelo em papel o um prototipo. Durante as últimas iterações, se produzem versões cada vez mais acabadas. O modelo em espiral se divide num número de actividades de enquadramento do trabalho, denominadas por regiões de tarefas. Geralmente, existem entre 3 e seis regiões. A figura representa um modelo em espiral que contem 6 regiões: Comunicação com o cliente: estabelecimento de comunicação entre o responsável pelo desenvolvimento e o cliente Planeamento: definição de recursos, tempo e outras informações relacionadas Análise de riscos: avaliação de riscos técnicos e de gestão Engenharia: construção de uma ou mais representações da aplicação Construção e acção: construção, teste, instalação e suporte ao utilizador (treino, documentação e prática) Avaliação do cliente: avaliação da reacção do cliente das representações do software criadas na etapa da engenharia e implementada na etapa de construção e acção Cada das regiões estão compostas por um conjunto de tarefas que se adaptam as características do projecto. Para projectos pequenos o número e formalidade das tarefas é baixo. Em projectos maiores, cada região terá uma série de tarefas definidas para atingir um nível mais alto de formalidade. Em todos os casos se realizam actividades de gestão da configuração e controlo da qualidade O melhor paradigma deve ser um modelo evolutivo de processo acoplado com um enfoque que fomenta a reutilização

Modelo Recursivo-Paralelo Realizar a análise suficiente para isolar as classes do problema e as conexões mais importantes Realizar um pequeno desenho para determinar se as classes e as conexões podem ser implementadas de maneira prática Extrair objectos reutilizáveis de uma biblioteca para construir um protótipo prévio Conduzir alguns testes para descobrir erros no protótipo Obter retro-alimentação do cliente sobre o protótipo Modificar o modelo de análise baseando-se na Análise, no Desenho e no Cliente

Modelo Recursivo-Paralelo Refinar o Desenho para acomodar as mudanças Construir objectos especiais (não disponíveis na biblioteca) Montar um novo protótipo usando Objectos da biblioteca Novos objectos Realizar provas para descobrir erros Obter retro-alimentação do cliente sobre o protótipo - Este enfoque continua até o protótipo evoluir para uma aplicação em produção!

Sequencia típica de um Processo OO em termos de actividades para o Plano de Projecto OO planificação testes extrair classes reutilizáveis análise desenho protótipo análises do cliente (…) classes reutilizáveis entrega ao cliente Revisão e Refinamento: revisões, avaliações do cliente e testes a cada incremento Variante do modelo iterativo e incremental. Proposto por B. Boehm como resposta as críticas sobre a falta dos outros processos evolutivos na utilização de prototipos e reutilização de software. Permite a construção rápida de aplicações em versões incrementais. Durante as primeiras iterações, a versão incremental poderia ser um modelo em papel o um prototipo. Durante as últimas iterações, se produzem versões cada vez mais acabadas. O modelo em espiral se divide num número de actividades de enquadramento do trabalho, denominadas por regiões de tarefas. Geralmente, existem entre 3 e seis regiões. A figura representa um modelo em espiral que contem 6 regiões: Comunicação com o cliente: estabelecimento de comunicação entre o responsável pelo desenvolvimento e o cliente Planeamento: definição de recursos, tempo e outras informações relacionadas Análise de riscos: avaliação de riscos técnicos e de gestão Engenharia: construção de uma ou mais representações da aplicação Construção e acção: construção, teste, instalação e suporte ao utilizador (treino, documentação e prática) Avaliação do cliente: avaliação da reacção do cliente das representações do software criadas na etapa da engenharia e implementada na etapa de construção e acção Cada das regiões estão compostas por um conjunto de tarefas que se adaptam as características do projecto. Para projectos pequenos o número e formalidade das tarefas é baixo. Em projectos maiores, cada região terá uma série de tarefas definidas para atingir um nível mais alto de formalidade. Em todos os casos se realizam actividades de gestão da configuração e controlo da qualidade

Identificação de Classes e Objectos Análise Sintáctica Gramática Sublinhar os substantivos do texto da narrativa do processo ou da Descrição do Âmbito do Sistema Descartar os sinónimos Um objecto nunca deve ser uma forma verbal!

Identificação: Formas de Manifestação Entidades externas (outros sistemas, pessoas) que produzem ou consomem informação a ser usada pelo sistema Coisas (cartas, apresentações, etc.) que são parte do domínio de informação do problema Ocorrências (acções que se repetem – ex. instalação) que ocorrem dentro do contexto de uma operação do sistema Papéis (director, engenheiro, vendedor, etc.) desempenhados por pessoas que interagem com o sistema

Identificação: Formas de Manifestação Unidades Organizacionais (divisão, grupo, equipa) Relevantes numa organização Estruturas (sensores, veículos de 4 rodas, etc.) que definem uma classe de objectos ou classes relacionadas de objectos Lugares (planta de produção, armazém de carga, etc.) que estabelecem o contexto do problema e a função geral do sistema

Identificação: Considerações para os Analistas Como saber se um objecto deve ser incluído (ou não) no Modelo de Análise OO? – Perguntem-se: A informação acerca dele deve ser lembra? ou seja, é um objecto persistente? Possui operações identificáveis que podem mudar o valor dos seus atributos? Possui atributos múltiplos? ou somente um atributo? Possui atributos comuns? que são aplicáveis a todas as ocorrências do objecto Possui operações comuns? São entidades externas? que produzem ou consomem informação do sistema? Se qualquer uma das respostas for SIM, o objecto deve ser incluído no modelo

Finalizando a identificação Alguns objectos descartados serão atributos dos objectos seleccionados Durante as iterações do Modelo de Processo OO (Modelo Recursivo-Paralelo) podem ser adicionados outros novos objectos

Boas Práticas de Desenvolvimento OO Alta Coesão Os métodos tendem a manipular um número limitado de atributos Baixo Acoplamento A classe tem pouca comunicação com outros elementos do sistema porque a comunicação ocorre (internamente) somente através de métodos declarados Polimorfismo Permite que operações diferentes tenham o mesmo nome Por exemplo: o método desenhar() para classes gráficas.. Reduz o acoplamento entre objectos tornando-os mais independentes evitar Herança Múltipla Pode dificultar a manutenção! Em geral, complica a hierarquia da classe e cria problemas potenciais no controle da Configuração (veremos no projecto) É mais coerente especializar (gerar) uma nova classe “filha”

para a próxima semana…

Plano de Projecto de SW Documento MS Word Project Map V.I.C.T.O.R. modelo proposto para a Lacertae SW Project Map tutorial do MS Project V.I.C.T.O.R. assistente automatizado para “Gerenciamento de Projetos” elaborado por uma empresa incubada na UFPE – Universidade Federal de Pernambuco