Engenharia de Software: Introdução Eliane Martins eliane@ic.unicamp.br Criado: mar/2002 Atualizado: mar/2006
Tópicos Sw de uso pessoal x Sw produto Evolução do papel do sw Características do sw A crise Mitos Objetivos da E/Sw O Processo 2
Referências I.Sommerville. Software Engineering. Addison-Wesley. 6ª edição, 2001, cap.3 R.S.Pressman. Software Engineering: a Practitioners Approach. Mc- Graw Hill,???, cap.??? B. Brügger. Component-based Software Engineering. Notas de aula. Universidade Técnica de Munique (TUM), Nov/1997. S.Easterbrook. Software Engineering I. Notas de aula. Universidade de Toronto, 2001. Obtido em julho/2004 no site: http://www.cs.toronto.edu/~sme C.R.Santos; V.L.P.Santoro; O.C.Fernandes. Processo Unificado. Apresentação no curso de MO409 2005. 3
Sw de uso pessoal: um programador um usuário vida curta Sw uso pessoal x Sw produto 4
Sw uso pessoal x Sw produto Sw de uso pessoal: um programador um usuário vida curta Sw produto: equipe de desenvolvimento múltiplos usuários longa duração enfoque sistemático para desenvolver e manter 5
Evolução do papel do sw Importância do sw em sistemas computacionais Causas: queda no custo do hw avanço da tecnologia do hw custo do desenvolvimento do sw custo de manutenção do sw 6
Evolução do papel do sw Importância do sw em sistemas computacionais Causas: queda no custo do hw avanço da tecnologia do mudança hw de enfoque no custo do desenvolvimento do sw desenvolvimento: hw sw custo de manutenção do demanda sw por sistemas computacionais Progama Apollo (1969): sw < 10Mbytes Progama Columbus : sw 100Mbytes [Sommerville2007, c.2] 7
Evolução do papel do sw Importância do sw em sistemas computacionais Causas: queda no custo do hw avanço da tecnologia do hw custo do desenvolvimento do sw custo de manutenção do sw complexidade do sw : novas técnicas de desenvolvimento e manutenção necessidade de equipes 8
Evolução do papel do sw Importância do sw em sistemas computacionais Causas: queda no custo do hw avanço da tecnologia do hw custo do desenvolvimento do sw custo de manutenção do sw custo com pessoal complexidade do sw 9
Evolução do papel do sw Importância do sw em sistemas computacionais Causas: queda no custo do hw avanço da tecnologia número do hw de sistemas em operação custos com manutenção custo do desenvolvimento do sw custo de manutenção do sw 10
Características do sw Sw x Hw: sw não é manufaturado sw é invisível, intangível, abstrato sw não é governado por leis físicas sw pode ser totalmente replicado sw é cada vez mais caro que o hw 11
% custo 120 100 80 60 40 20 0 Hardware Desenvolvi mento do sw Mnutenção do sw 1955 1970 1985 [B.Boehm, 1976] 12
Sw x Hw: Características do sw sw não se desgasta com o uso, mas se degrada com as modificações hw sw taxa de falhas mortalidade infantil desgaste taxa de falhas alteração real ideal tempo tempo 13
Sw x Hw: Características do sw sw não se desgasta com o uso, mas se degrada com as modificações custos com manutenção Desenvolvimento Manutenção 35-40% Desenvolvimento Desenvolvimenttenção Manu- 40-60% Manutenção 70-80% 1970 1980 1990 14
A crise do sw Crise ou doença crônica? A maioria dos grandes sistemas de sw: ultrapassam os custos pré-estabelecidos, são entregues com atraso, não correspondem ao que o usuário esperava. It s late, costly, incompetent - but try firing a computer system J.Rothfeder, 1989. 15
A crise do sw 2% 3% Utilizável 47% 29% Utilizável após correções Não terminados Abandonados 19% Nunca usados [Lehman 90] 16
Exemplos Anos 80: Força Aérea Americana, sw de comando e controle: custo inicial estimado: U$400.000,00 custo final: U$3.200.000,00 Sw de recebimento de imposto de renda (EUA): [Jalote97, 1.1.2] qualidade: o sistema se mostrou inadequado para a carga esperada custo: a Receita Federal dos EUA gastou mais U$90.000.000,00 para corrigir o sw que custou U$103.000.000,00 devido ao atraso, a RF ainda teve de pagar mais U$63.000.000,00 de multas por atraso e juros [B.Brügge 97, Notas de curso TUM] 17
Exemplos Ônibus Espacial: Custo: U$10.000.000.000,00 (vários milhões a mais do que o estimado) Prazo: 3 anos de atraso [B.Brügge 97, Notas de curso TUM] Qualidade: primeiro lançamento do Columbia foi cancelado devido a problemas de sincronização de seus 5 computadores de bordo causa: modificação feita 2 anos antes, em que tempo de espera de um tratador de interrupção passou de 50ms para 80ms o erro era um evento raro, tanto que não foi detectado durante as mais de mil horas de teste muitos erros ainda subsistem. Os astronautas recebem um livro contendo os problemas de sw que já são conhecidos. 18
Mitos - 1 Uso de computadores de última geração qualidade do sw Uso de ferramentas CASE de última geração qualidade do sw Atraso no desenvolvimento aumentar equipe Desenvolvimento pode ser iniciado com descrição geral dos objetivos; detalhes são acrescentados depois 19
Mitos - 2 Mudanças nos requisitos são facilmente acomodadas pois o sw é flexível Sw pronto equipe de sw é desnecessária Enquanto o sw não está rodando, não há meios de se avaliar sua qualidade O único produto do desenvolvimento de sw é o programa rodando 20
Engenharia de Software - surgimento Surgiu em 1968-1969 em reunião da OTAN O termo veio do nome da conferência Motivação: Dificuldade da indústria em produzir software grande e complexo Participantes: Manufatura de computadores, usuários, software houses, academia Para documentos iniciais veja em: http://homepages.cs.ncl.ac.uk/brian.randell/nato/ 21
Sistemas socio-técnicos Grande desafio da Engenharia de Software hoje em dia Sistemas que envolvem hw, sw, pessoas e mais políticas e regras organizacionais Têm propriedades que devem ser satisfeitas pelo sistema como um todo, e não por suas partes individuais São geralmente indeterministas, i.e, para as mesmas entradas, nem sempre são produzidas as mesmas saídas (pode depender das reações humanas) Políticas e regras organizacionais variam com o tempo 22
Engenharia de Software Uma disciplina que reúne metodologias, métodos e ferramentas a serem utilizados desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software. [Carvalho e Chiossi 2001] Conjunto de metodologias, métodos e ferramentas que auxiliam na produção de software de alta qualidade dentro dos prazos e custos esperados. [B.Brügge 97, Notas de curso TUM] 23
Engenharia de Software Método: procedimento formal (ou sistemático) que usa notações bem definidas para obter resultados Metodologia: conjunto de métodos aplicados ao longo do desenvolvimento, unificados por uma abordagem filosófica Ferramenta: instrumento ou software que apoia a realização de um método Processo: É o que as pessoas fazem para adquirir, desenvolver, manter ou melhorar produtos de software 24
Processo Modelo genérico: definição desenvolvimento manutenção 25
Processo Modelo genérico: definição desenvolvimento O quê deve ser feito: que dados serão usados? que funções serão realizadas? quais as restrições? quais os custos? quais os riscos? manutenção quais os prazos? 26
Processo Conjunto de atividades necessárias Como deve para ser feito: obter um produto de sw Modelo genérico: definição desenvolvimento como estruturar o sw? como implementar os dados? como implementar as funções? como implementar as restrições? como verificar se o sw está sendo desenvolvido corretamente? como validar o produto desenvolvido? manutenção 27
Processo Conjunto de atividades necessárias para se obter um produto de sw Modelo genérico: definição desenvolvimento Alterações: corrigir bugs ; adaptar a novos ambientes; acrescentar novos requisitos; melhorar a manutenção; determinar se modificações não fizeram o sw regredir; manutenção 28
Processo Modelo genérico levando em conta Verificação e Validação (V&V) definição Validação: o sw faz o que o cliente quer? desenvolvimento Verificação: manutenção o sw correto está sendo produzido? 29
Modelos de processo: para que? Objetivos O que deve ser feito a seguir? Por quanto tempo deve-se continuar a fazê-lo? Importância Gerente: controlar o desenvolvimento, aquisição e manutenção do sw Desenvolvedor: obter uma base para produzir adquirir ou manter, de maneira eficiente, um sw que satisfaça aos requisitos estabelecidos 30
Modelos de Processo e de Melhoria de Processos Modelos de melhoria de processo: CMMI, SPICE, MPS.BR,... Descrição de processo genérico: papéis, atividades, artefatos Ex.: Processo Unificado boas práticas, níveis de capacidade, áreas chave de processo,... Descrição de processo da empresa: papéis, atividades, artefatos Processo da empresa: o que as pessoas fazem [Clênio S. 2005] 31
Principais modelos de processo genéricos Existem vários modelos genéricos de processo de ciclo de vida: codifica e corrige cascata ( waterfall model ) variante do cascata evolutivo incremental espiral transformacional processo sala limpa baseado em componentes 32
Passos: Modelo codifica e corrige 1. Escrever o código 2. Eliminar os bugs Necessidades do usuário desenvolvimento produto 33
Dificuldades: Modelo codifica e corrige após um certo número de alterações a estrutura do código era perdida custo com alterações necessidade de uma fase de projeto freqüentemente o sw, mesmo bem estruturado, não satisfazia ao usuário necessidade de uma fase de análise de requisitos custo de correção do código era alto necessidade de uma fase de testes 34
Modelo cascata Características: criado em 1970 consistente com modelo de programação top-down: requisitos (+ abstrato) código Requisitos Análise Projeto Codificação Testes Operação e Manutenção 35
Modelo cascata Características: O sw nem sempre pode ser desenvolvido de forma top-down Dificilmente os requisitos são obtidos de forma completa, precisa e consistente logo de início Uma versão executável do sistema só é obtida ao final do desenvolvimento, quando então se avalia a qualidade 36
Modelo cascata - variante Uma das variantes do modelo, apresentada em [Boehm 1976], incorpora atividades de verificação e validação (V&V): Verificação: o produto está sendo construído corretamente? Validação: o produto correto está sendo construído? Requisitos Análise Projeto Codificação Testes Operação e Manutenção 37
Modelo cascata - variante Características: Realimentação entre as fases permite melhoria na qualidade desde cedo Ainda exigência de requisitos completos, precisos e consistentes desde cedo 38
Modelo baseado em protótipo descartável Desenvolvimento e implementação de produto inicial (protótipo) que é submetido ao usuário para avaliação Uso de um protótipo descartável ( throw-away prototyping ) ou rápido projeto, implementação e testes são rápidos e informais o protótipo é avaliado, ajudando a consolidar requisitos necessidades do usuário Análise Projeto Codificação Testes Operação e Manutenção Projeto do protótipo Refinamento Uso do protótipo Análise dos resultados Realimentação do usuário 39
Protótipo descartável Usuário definiu objetivos gerais do sw, mas não detalhes sobre entradas, procedimentos e saídas O desenvolvedor quer avaliar a eficiência de um algoritmo, ou a forma da interface-usuário Usuários são envolvidos desde cedo na avaliação do sw Requisitos ficam estáveis mais cedo O usuário se contenta com o protótipo e não tem paciência de esperar pelo produto final qualidade do sw O desenvolvedor usa o protótipo como um produto final, por estar familiarizado com ele qualidade do sw O processo não é visível (não há documentação) difícil de gerenciar 40
Protótipo descartável Definir as regras do jogo no início: desenvolvedores e clientes devem estar cientes de que o protótipo será descartado tão logo os objetivos tenham sido atingidos Adaptar gerenciamento Usar ferramentas que facilitem a criação de protótipos 41
Modelo em fases Voltados para sistemas grandes: pode-se usar diferentes abordagens para diferentes partes do sistema permite repetir partes do processo na medida em que os requisitos evoluem Principais abordagens: evolutiva (evolutionary development) incremental espiral 42
Desenvolvimento evolutivo - 1 Também chamado de processo exploratório Protótipo vai evoluindo até chegar ao sistema final O sw é produzido em partes menores (incrementos) Cada incremento é entregue ao usuário O primeiro incremento geralmente constitui o núcleo do sistema, contendo todos os requisitos básicos já conhecidos Os resultados da avaliação do desenvolvimento da versão precedente servem de base para produção do próximo incremento Cada versão (novo incremento) incorpora novos requisitos 43
Desenvolvimento evolutivo - 2 Ex.: sistema de editoração eletrônica 1º incremento: funções básicas de manipulação e edição de arquivos; produção de documentos 2º incremento: funções avançadas de edição e produção de documentos 3º incremento: verificador de ortografia e gramática... 44
incremento 1 análise projeto codificação testes integração O&M incremento 2 análise projeto codificação testes integração O&M incremento N... análise projeto codificação testes integração O&M O&M: Operação e Manutenção tempo [Sommerville96] 45
Desenvolvimento evolutivo modelo mais realista que o cascata, pois não exige requisitos completos desde o início: à medida em que o usuário utiliza partes já prontas, pode identificar novos requisitos útil quando equipe é pequena para desenvolver todo o sistema partes mais difíceis (ou básicas) podem ser produzidas primeiro, sendo avaliadas mais tempo interação cliente/usuáriodesenvolvedores incrementos continuam a ser desenvolvidos segundo o modelo cascata custo de gerenciamento não existe especificação completa antes que o último incremento tenha sido desenvolvido problema se especificação faz parte do contrato com o cliente 46
Desenvolvimento incremental Proposto por H. Mills em 1980 O sistema é desenvolvido por partes Clientes identificam requisitos (serviços a serem fornecidos) e classificam-nos por ordem de prioridade Número e tamanho dos incrementos é definido Distribuem-se os serviços pelos incrementos de acordo com prioridades: serviços mais prioritários são entregues antes Cada novo incremento acrescenta um novo requisito ao sistema Os incrementos são produzidos utilizando-se o processo de desenvolvimento preferido 47
Desenvolvimento incremental Define requisitos preliminares Estabelece nº de incrementos Atribui requisitos aos incrementos Projeta arquitetura do sistema Desenvolve incremento Valida o incremento Integra incremento sistema incompleto Valida o sistema sistema final 48
Desenvolvimento incremental Diminui o retrabalho no processo de desenvolvimento do modelo cascata Os clientes não precisam esperar que o sistema final seja entregue Partes mais básicas podem ser produzidas primeiro, sendo validadas mais vezes Clientes podem usar incrementos entregues como protótipos para ajudar no levantamento de requisitos dos próximos Diminui o risco de insucesso total do projeto: alguns incrementos deverão ser bem sucedidos Incrementos devem ser pequenos (< 20.000 LOC) e cada incremento deve realizar pelo menos um serviço pode ser difícil mapear serviços em incrementos Requisitos só são detalhados no momento em que os incrementos são desenvolvidos difícil identificar recursos comuns a mais de um incremento 49
Modelo espiral Características: Proposto por Barry Boehm, 1988 Desenvolvimento incremental: a cada volta na espiral, versões mais completas do sw são construídas Análise de risco a cada novo incremento: riscos: circunstâncias adversas que podem comprometer tanto o processo de desenvolvimento quanto a qualidade do produto Possibilidade de incorporar diversos modelos de processo: escolha do modelo de processo depende dos resultados de avaliações do produto gerado em etapas anteriores e na análise de risco feita no início da etapa corrente 50
Modelo Espiral Ativação: determina objetivos, alternativas e restrições Análise dos riscos: avalia alternativas; identifica e resolve riscos custos e prazos Plano de Desenvolvimento Plano de Testes e Integração Planejamento da próxima iteração Validação dos Requisitos Operação V&V do Projeto Preliminar Testes e integração Codificação custos custos custos e prazos e prazos e prazos protótipo 1 protótipo 2 protótipo 3 Plano de Requisitos, conceito Modelo de ciclo de Requisitos Projeto de vida operação Preliminar protótipo 4 Projeto Detalhado Desenvolvimento: desenvolve; verifica 51
Modelo espiral Passos: Identificação dos objetivos do incremento, meios alternativos para implementá-lo, restrições Planejamento e análise de riscos de cada alternativa, determinando estratégias para reagir aos mesmos (ou abandonar o Projeto) Desenvolver o incremento, usando o modelo de desenvolvimento mais adequado ao mesmo Avaliação dos resultados da etapa anterior e planejamento da próxima fase 52
Modelo espiral Acompanha todo o ciclo de vida do sw Combina modelo evolutivo com cascata (ou outros) Permite a usuários e desenvolvedores identificar riscos e se preparar para evitá-los ou contorná-los Ideal para grandes Projetos É difícil convencer os clientes de que o modelo evolutivo é controlável Requer especialistas em identificação e análise de riscos Há poucos dados sobre sua eficácia 53
Modelo transformacional Característica: Passos: produto é desenvolvido a partir de transformações sucessivas: especificação dos requisitos... código 1 descrição dos requisitos preliminares (formal) 2 transformações sucessivas dessa descrição até obter código 3 repetição dos passos 1 e 2 para refinar o produto 4 uso do produto obtido 5 refinamento da especificação com base nos resultados do uso, repetindo-se passos 1 a 4 54
Linguagens de 4ª Geração (4GL) O termo 4GL foi cunhado por James Martin para designar linguagens de alto nível, não orientadas a procedimentos e construídas em torno de um banco de dados. Depois disso, com a experiência adquirida em certas áreas, surgiram as linguagens específicas para um domínio de aplicação: Linguagens para geração de relatórios: descrição de formato de dados e do relatório (ex.: Speedware http://www.speedware.com) Linguagens de consulta para BDs: SQL PostScript, PDF: linguagens para descrição de páginas de impressão contendo texto e gráficos Mathematica: realização de cálculos matemáticos, geração de gráficos,... http://www.wolfram.com/products/mathematica/tour/... 55
Modelo transformacional Tempo de desenvolvimento para aplicações pequenas e médias diminui Uso de linguagens de 4ª geração (4GL) se expande para diversas áreas, facilitado pelo uso de CASEs e geradores de código Algumas 4GL não são fáceis de usar Código gerado automaticamente não é eficiente Manutenibilidade ainda é discutível Fases de análise, projeto e testes mais elaboradas para o caso de sistemas grandes 56
Modelo baseado em componentes Componentes: artefatos de sw construídos para reuso artefatos: planos de Projeto, estimativas de custo, arquitetura, modelos de requisitos e/ou projeto, código fonte, casos de teste,... Desenvolvimento baseado em componentes: incorpora características do modelo espiral mas...... sw é construído a partir da composição de componentes já existentes, que podem tanto ser de terceiros quanto comerciais (COTS) ganho em produtividade e custo mas componente precisa ter boa qualidade! 57
Desenvolvimento com reúso Identificar componentes candidatos Buscar em biblioteca de componentes Extrair os componentes disponíveis Construir a nª iteração do sistema Inserir os novos componentes na biblioteca Construir os componentes não encontrados 58
Modelo para construção de componentes Análise de domínio Desenvolvimento da arquitetura Desenvolvimento do componente Modelo de domínio Modelo estrutural Repositório de componentes 59
Especificação dos Requisitos Modelo orientado para os testes (Modelo V) Revisão dos Requisitos Revisão dos testes de Sistemas e de Aceitação Especificação, Projeto e Implementação dos testes de Sistemas e de Aceitação Execuçãodos testes de Sistemas e de Aceitação Projeto Revisão do Projeto Revisão dos testes de Integração Especificação, Projeto e Implementação dos testes de Integração Execução dos testes de Integração Codificação Revisão do Código Revisão dos testes de Unidades Execução dos testes de Unidades Especificação, Projeto e Implementação dos testes de Unidade 60
Modelo V para sistemas críticos Espec Req Inocuidade do sistema Arquitetura do sistema Especificação dos Requisitos de Inocuidade do Software Arquitetura do Software Projeto do Software Base: IEC 61508 Teste de Validação Teste de Integração (Componentes, subsistemas, hw) Teste de Integração (Módulos) Projeto de um Módulo do Sw Teste de um Módulo do Sw Codificação 61
Exemplo de modelo genérico de processo O Processo Unificado (UP, de Unified Process): É um modelo genérico de um processo de desenvolvimento É iterativo e incremental É baseado em componentes Utiliza a UML (Unified Modeling Language) UML A Linguagem de Modelagem Unificada é um método aberto usado para especificar, visualizar, construir e documentar artefatos de um sistema de sw orientado a objetos. Permite que o desenvolvedor visualize o produto de seus trabalhos em diagramas padronizados 62
Processo Unificado Ciclo de vida UP repete ciclos até a aposentadoria do produto Cada ciclo gera um produto liberado para uso Cada ciclo possui quatro fases Cada fase é dividida em iterações A cada iteração é gerado um conjunto de artefatos Há um marco (milestone) ao final de cada fase 63
Fases de um ciclo do UP tempo Cada ciclo do UP possui 4 fases: Concepção: Definição do escopo e fronteiras do sistema Elaboração: Criação da arquitetura Plano de projeto e riscos Construção Desenvolvimento iterativo e incremental Transição Implantação e evolução 64
Workflows de cada fase Cada iteração é composta de passos (workflows): Requisitos Análise Projeto Implementação Testes Modelo Caso de Uso Modelo Análise Modelo Projeto Modelo Implantação Modelo Implementação Modelo Teste 65
Fases e Workflows 66
Papéis e Responsabilidades Analistas: coordena a modelagem dos processo e executa o levantamento das regras de negócios envolvidos no projeto Analistas de Negócios Analistas de Sistemas coordena o levantamento de requisitos e a modelagem especificação de casos de uso 67
Papéis e Responsabilidades Desenvolvedores: Estabelece a estrutura geral da arquitetura para cada uma de suas visões Arquiteto: Integrador Responsável pelo planejamento das integrações do projeto e dos componentes implentados pelos programadores Programador Projetista de É o responsável pela implementação e testes dos componentes de acordo com os padrões estabelecidos pelo projeto Banco de Dados Define as construções específicas de bancos de dados necessárias ao armazenamento,obtenção e exclusão de dados 68
Papéis e Responsabilidades Gerentes: É responsável pela disponibilização da infra-estrutura geral de configuração e mudanças do projeto para a equipe de desenvolvimento Configuração Implantação Projeto É responsável pelo planejamento da transição do produto para os usuários Aloca recursos, define prioridades, coordena as interações com os clientes e usuários 69
Papéis e Responsabilidades Equipe de Testes Responsável pelo planejamento e avaliação dos resultados dos testes Gerente de testes Projetista de teste Implementador Responsável pelo projeto das entradas e do ambiente de testes dos testes Responsável pela implementação, configuração e execução dos testes 70
Desenvolvimento dirigido por modelos MDD (Model Driven Development) Foco do desenvolvimento de sw: Programação modelos e transformações entre modelos Modelos completos e precisos, a partir dos quais pode-se gerar código (e testes) automaticamente 71
Motivação Abordagens tradicionais: Fazem pouco uso de abstração, reuso e automação Mapeamento de modelos para código ainda é feito manualmente Modelos de brinquedo, que não são mantidos, atualizados e reutilizados Codificação é o foco do desenvolvimento 72
MDA MDA (Model-Driven Architecture) Framework para o desenvolvimento dirigido por modelos Iniciativa da OMG (Object Management Group) Fonte: G.Elias. MDA. Tutorial SBCARS 2007. 73
O que significa Arquitetura em MDA? Estende o significado de Arquitetura de Software para uma arquitetura de um sistema de modelos: Modelos são conectados e estruturados por relacionamentos de transformação Especifica os tipos de modelos, como podem ser preparados e o tipo de relacionamentos entre eles 74
Visões na MDA Pontos de vista: formas diferentes de ver um sistema Visão: representação do sistema segundo um ponto de vista Visões da MDA: CIM (Computational Independent Model) PIM (Platform Independent Model) PSM (Platform Specific Model) 75
Plataforma Plataforma genérica: Objetos, processos,... Plataforma específica de tecnologia Corba, Java2 components,... Plataforma específica de fabricante Microsoft.NET, IBM Websphere,... Existem diferentes graus de independência de plataforma 76
Visão CIM Foca no sistema, no ambiente do sistema e nos seus requisitos Abstrai (esconde) detalhes da arquitetura do sistema Abstrai detalhes da plataforma de execução do sistema Usa vocabulário do domínio do problema 77
Visão PIM Foca nas operações (serviços) do sistema, abstraindo detalhes sobre a plataforma Permite que a especificação sirva para diversas plataformas Pode usar uma linguagem de modelagem de propósito geral ou específica de uma plataforma genérica 78
Visão PSM PIM + detalhes inerentes a uma plataforma específica (de tecnologia, de fabricante) Inclui representações mais detalhadas do que aquelas do PIM + representações de aspectos que não aparecem no PIM 79
Modelos Para cada tipo de visão, tem-se diferentes tipos de modelos: CIM Modelo de domínio ou de negócios PIM Modelo do sistema PSM Modelo detalhado do sistema + código PM (Modelo de plataforma): Descreve a plataforma e como utilizá-la 80
Transformação entre modelos Modelo Independente de Computação (CIM) Modelo Independente de Plataforma (PIM) Transformação Modelos Específicos de Plataforma (PSM) J2EE Corba.Net 81
Ciclo de vida com MDA Requisitos Análise Projeto Codificação Testes Entrega textual PIM PSM código código Modelos não são unicamente parte de documentos, mas são a fonte para o desenvolvimento Realimentação rápida através de simulação e geração automática de código Geração de testes com base nos modelos Modelos específicos de domínio facilitam a comunicação com usuários 84
Desenvolvimento de sw: Comentários finais diferente de outros produtos da Engenharia muitos dos modelos de desenvolvimento existentes não se aplicam; por exemplo, não existe uma etapa de fabricação o comportamento do sw não é completamente conhecido Modelos de desenvolvimento de sw: permite identificar áreas problemáticas permite sintetizar as diferentes alternativas para a solução de dificuldades dá suporte ao gerenciamento existem várias visões: cascata, em fases,... nenhum modelo é perfeito 85
Escolha do modelo depende: da natureza do Projeto Comentários finais da equipe de desenvolvimento e do estilo de gerenciamento do grau de sofisticação do cliente/usuário do ambiente de desenvolvimento Atividades essenciais de um bom processo: descrição do problema (o quê deve ser feito?) descrição da solução (como deve ser feito?) verificação (a solução adotada responde ao problema descrito?) validação (o problema correto foi resolvido?) 86