Cap.

3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1]
2

Tópicos

ENGENHARIA DE SOFTWARE
PARTE 1 INTRODUÇÃO E VISÃO GERAL

Introdução A Programação como Fonte de Inovação Desenvolvimento Ad-Hoc As Metodologias Estruturadas As Metodologias Orientadas por Objetos Outras Metodologias

C AP. 3 – E V O L U Ç ÃO D AS M E TO D O L O G I A S D E D E S E NV O LV I M E N TO D E S O F T WAR E

Comparação de Metodologias

Engenharia de Software - 2011/2012

Carlos Barrico - Departamento Informática da UBI

Engenharia de Software - 2011/2012

Carlos Barrico - Departamento Informática da UBI

Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1]
3

Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1]
4

Introdução

Introdução

1965 - para Dijkstra qualquer pedaço de código é essencialmente uma série de instruções de natureza matemática, e como tal é possível provar a sua correção. 1967 - A expressão engenharia de software foi pela primeira vez aplicada numa conferência da NATO. 1969 – Dijkstra realçou a importância da preocupação com a prevenção de erros, para além de utilizar pela primeira vez a expressão “programação estruturada”. 1971 - Niklaus Wirth publicou um artigo com base no trabalho de Dijkstra e Bohm, defendendo a ideia da construção de programas de forma incremental, à custa de unidades mais elementares.

1972 – Parnas publicou o seu célebre artigo sobre encapsulamento de informação, no qual reforçava a ideia de Wirth relativamente à importância de dividir um programa em unidades mais elementares, cada uma delas apenas disponibilizando um conjunto de

funcionalidades, mas “escondendo” a respetiva implementação. Apesar da importância dos conceitos propostos nas décadas de 1960 e 1970, e que tiveram impacto na atividade e técnicas de programação utilizadas, já nesta altura se reconhecia que este esforço não seria suficiente, e que era preciso rentabilizar o trabalho do programador através de medidas com impacto em áreas que não apenas a programação.

Engenharia de Software - 2011/2012

Carlos Barrico - Departamento Informática da UBI

Engenharia de Software - 2011/2012

Carlos Barrico - Departamento Informática da UBI

Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1]
5

Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1]
6

Introdução

A Programação como Fonte de Inovação

Constantine tentou identificar mecanismos que possibilitassem que a conceção inadequada de software fosse evitada desde o início, aquando da identificação de requisitos. Constantine, Stevens e Myers propuseram o conceito de Composite Design (“desenho estruturado”) que procurava representar sob a forma de diagramas as ações de um programa que posteriormente seriam codificadas. Esta foi uma das primeiras iniciativas para definir um processo mais consistente e abrangente, aplicado a todo o ciclo de desenvolvimento de software.

Até muito recentemente, os principais saltos qualitativos em termos de conceitos com impacto significativo nas áreas abrangidas pela

engenharia de software, iniciaram-se sempre pela área das linguagens de programação.

Engenharia de Software - 2011/2012

Carlos Barrico - Departamento Informática da UBI

Engenharia de Software - 2011/2012

Carlos Barrico - Departamento Informática da UBI

Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1]
7

Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1]
8

A Programação como Fonte de Inovação

A Programação como Fonte de Inovação

Evolução das principais técnicas e abordagens de programação, consoante o grau de complexidade e dimensão do software.

Primeira fase:
Surgiram as linguagens de baixo nível, muito próximas da tecnologia e fortemente condicionadas por ela, na qual se incluem as linguagens máquina, em que as instruções eram meras sequências de bits. A primeira iniciativa no sentido de elevar a atividade de programação surgiu com o aparecimento das linguagens assembly, que utilizavam mnemónicas como forma de substituir o código máquina.

Engenharia de Software - 2011/2012

Carlos Barrico - Departamento Informática da UBI

Engenharia de Software - 2011/2012

Carlos Barrico - Departamento Informática da UBI

3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 12 A Programação como Fonte de Inovação A Programação como Fonte de Inovação Terceira fase: Terceira fase: Caracterizada pelo desenvolvimento de sistemas de maior dimensão com base em linguagens estruturadas de mais alto nível (por ex:. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 11 Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 10 A Programação como Fonte de Inovação A Programação como Fonte de Inovação Segunda fase: Segunda fase: A primeira alteração com impacto deu-se com as primeiras linguagens simbólicas (Fortran. Gradualmente foram ganhando peso as para aplicações comerciais (Cobol).2011/2012 Carlos Barrico . sequências.Departamento Informática da UBI Engenharia de Software .Departamento Informática da UBI . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 9 Cap. Aparecimento da expressão “código esparguete”. Cobol). Algol.Cap. Pascal. No entanto. constituídos à custa de construções simples (isto é. Os programas construídos com recurso às linguagens estruturadas apresentavam uma organização em blocos de código.2011/2012 Carlos Barrico .2011/2012 Carlos Barrico . numa tentativa de aproximar mais as técnicas de programar do processo de raciocínio humano.2011/2012 Carlos Barrico . Estas linguagens eram eminentemente imperativas. a grande ausência de regras sintáticas e semânticas possibilitava a construção de programas difíceis de compreender.Departamento Informática da UBI Cap. Engenharia de Software . As primeiras linguagens eram utilizadas sobretudo para cálculos científicos e de engenharia (Fortran). Engenharia de Software . em que as instruções diziam o que se fazia.Departamento Informática da UBI Engenharia de Software . C. 4GL). que eram suportadas por métodos estruturados. seleções e repetições). que resultou da utilização abusiva da instrução GOTO.

Departamento Informática da UBI .2011/2012 Carlos Barrico .2011/2012 Carlos Barrico .Departamento Informática da UBI Engenharia de Software . era ainda possível aceder do exterior aos dados declarados dentro de um módulo. Terceira fase (Modula-2): A linguagem Modula-2 (definida pelo mesmo autor da linguagem Pascal. o que não facilitava a decomposição do problema noutros mais elementares nem suportava adequadamente o trabalho em equipa. todos localizados fisicamente no mesmo ficheiro.Departamento Informática da UBI Engenharia de Software . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 13 Cap.2011/2012 Carlos Barrico . A ideia era agrupar num módulo dados e código.Departamento Informática da UBI Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 16 A Programação como Fonte de Inovação A Programação como Fonte de Inovação Terceira fase (tipo de dados abstrato): De forma a impossibilitar o acesso do exterior aos dados dentro dos módulos. e dificultando a verificação da consistência do sistema. Utilização abusiva dos dados globais a um programa. Quarta fase: Pela primeira vez. Estes novos tipos de dados permitem “esconder” totalmente partes da sua implementação (quer ao nível dos dados quer do código). que estivessem relacionados de forma a limitar as interações entre módulos à invocação de funções. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 14 A Programação como Fonte de Inovação A Programação como Fonte de Inovação Terceira fase (problemas surgidos): O aumento da complexidade e dimensão dos programas causou graves problemas nas técnicas de programação. Engenharia de Software . tornando difícil perceber quem manipulava que informação. No entanto. Engenharia de Software . e disponibilizar para o exterior o que se designa por interface. os teóricos propuseram o conceito de tipo de dados abstrato. foi possível definir uma associação tão forte entre dados e código. Niklaus Wirth) introduziu o conceito de módulo. cuja principal concretização prática ocorreu na linguagem ADA. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 15 Cap. pois os programas eram constituídos por uma sequência de blocos de instruções.Cap. possibilitavam que todas as instruções de um programa acedessem a esses dados. enquanto bloco de código no qual um programa se poderia decompor.2011/2012 Carlos Barrico .

Engenharia de Software . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 18 A Programação como Fonte de Inovação A Programação como Fonte de Inovação Quarta fase: A evolução dos conceitos de módulo e tipo de dados abstrato. e utilização de ambientes de desenvolvimento. Object Pascal. Engenharia de Software . o que exige o suporte por parte de tecnologias avançadas como sejam frameworks aplicacionais. o que não se verifica nos segundos. …). conduziu naturalmente ao aparecimento das linguagens orientadas por objetos (Smalltalk.2011/2012 Carlos Barrico . e (4) objetos. em termos de abstração e de encapsulamento da informação. componentes de software. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 20 A Programação como Fonte de Inovação A Programação como Fonte de Inovação Evolução dos conceitos de abstração nas linguagens de programação. (3) tipos de dados abstratos. A principal distinção entre objetos e tipos de dados abstratos. o desenvolvimento de software é ainda mais complexo e de maior dimensão.Cap. Nesta fase.Departamento Informática da UBI Cap.Departamento Informática da UBI . (2) módulo. é o suporte à noção de herança pelos primeiros. Engenharia de Software .2011/2012 Carlos Barrico .Departamento Informática da UBI A figura seguinte apresenta um modelo simplificado que demonstra a visibilidade dos dados e como estes se encontram relacionados com o código.2011/2012 Carlos Barrico .2011/2012 Carlos Barrico . A figura seguinte apresenta um diagrama que resume a evolução de algumas linguagens de programação nos últimos 50 anos.Departamento Informática da UBI Engenharia de Software . Java. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 17 Cap. frameworks de middleware. relativamente a cada um dos conceitos acima referidos: (1) programa. C++. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 19 Cap.

Sistemas de acesso à informação pouco flexíveis. as primeiras aplicações foram construídas sem usar uma metodologia de desenvolvimento formal (“programar e corrigir” .2011/2012 Carlos Barrico . em particular nas capacidades limitadas do hardware da altura.2011/2012 Carlos Barrico . A atenção estava concentrada na programação.Departamento Informática da UBI Engenharia de Software . utilizando a linguagem Cobol para programar.Departamento Informática da UBI Engenharia de Software .2011/2012 Carlos Barrico .Departamento Informática da UBI Cap.2011/2012 Carlos Barrico . Tarefas de desenvolvimento muito demoradas. mas raramente tinham a preocupação de compreender o negócio e de utilizar um discurso e expressões aceites e compreendidas por pessoas não técnicas. uma vez que as aplicações eram simples. que desenvolvia e testava os programas. tecnologias de armazenamento de informação. Engenharia de Software . tal situação tornou-se cada vez mais problemática. limitando-se a substituir (de forma limitada) tarefas realizadas manualmente por processos automáticos. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 22 O Desenvolvimento Ad-Hoc O Desenvolvimento Ad-Hoc Em face das potencialidades limitadas disponibilizadas ao nível das linguagens de programação. Inexistência de ferramentas de apoio a todo o processo. sistemas operativos. que quando muito tinham uma perspetiva ad-hoc e eram de natureza empírica. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 23 Cap. Não eram aplicados técnicas ou mecanismos de controlo e de gestão de projeto. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 24 O Desenvolvimento Ad-Hoc O Desenvolvimento Ad-Hoc Estes desenvolvimentos eram caracterizados por: Envolvimento limitado dos utilizadores. o que justificava o significativo peso relativo das tarefas de manutenção e a consequente diminuição do tempo disponível para o desenvolvimento de novas soluções. …) As profissões por excelência na área de informática eram de programador. Os requisitos dos utilizadores eram relegados para segundo plano. e ficheiros para o armazenamento da informação. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 21 Cap. A fraca qualidade do produto final implicava correções frequentes. o que não constituía um problema demasiado grave. Engenharia de Software . e de operador.Departamento Informática da UBI .build and fix). Fraca utilização de técnicas de análise e desenho. que os executava.Cap. À medida que a complexidade aumentou. e dos restantes componentes de suporte tecnológico (computadores. Identificação de requisitos efetuada de forma inadequada. e por isso estes ultrapassavam frequentemente custos e prazos estimados. e na resolução das diversas restrições de natureza técnica. Muitas organizações implementaram sistemas em ambientes proprietários (tipo mainframe). o que foi ainda agravado por outras situações: Os informáticos eram reconhecidamente bons programadores.

e introduzir técnicas baseadas nas melhores práticas no processo de análise e desenho. documentação. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 27 Cap. Análise Orgânica mais centrada nos conceitos e nos dados das encapsulamento da informação. e de metodologias de desenvolvimento de software. regras. notações.2011/2012 Carlos Barrico .Departamento Informática da UBI . com base na definição de blocos de código que permitiam algum nível de autonomia e de orientadas segundo uma de duas abordagens: Análise Funcional .2011/2012 Carlos Barrico . algoritmos e atividades são a preocupação central do engenheiro de software.2011/2012 Carlos Barrico . Era facilmente concretizada (ou mesmo condicionada) pela estrutura que as linguagens de programação tradicionais ofereciam.Departamento Informática da UBI Engenharia de Software . Engenharia de Software .Cap. Análise Funcional: as funções. Engenharia de Software . ferramentas.Departamento Informática da UBI Engenharia de Software .Departamento Informática da UBI Cap. Estrutura era pouco flexível. a possibilidade dos dados serem globalmente visíveis e manipulados por todo o programa (o que era então permitido pelas linguagens de programação).mais orientada para a decomposição funcional do sistema e a identificação dos respetivos processos. técnicas. técnicas de gestão. e menos à programação. etc. Estas metodologias tinham por objetivo formalizar o processo de identificação de requisitos. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 26 As Metodologias Estruturadas As Metodologias Estruturadas – Contexto e Motivação Durante os anos 1970 e 1980 assistiu-se a um importante salto qualitativo com a introdução de um conjunto de metodologias que se baseavam essencialmente em técnicas estruturadas de decomposição funcional.2011/2012 Carlos Barrico . com o objetivo de prestar mais atenção ao processo global. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 28 As Metodologias Estruturadas – Contexto e Motivação As Metodologias Estruturadas – Contexto e Motivação As metodologias estruturadas tradicionais estavam essencialmente Análise Funcional (cont). 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 25 Cap. incide toda a análise nas funcionalidades que o sistema deve realizar.. no sentido da incorporação de novas funcionalidades e correção de erros de implementação. intervenientes. organizações. com inputs e outputs. Foi neste contexto que apareceram pela primeira vez os conceitos de ciclo de vida. de modo a reduzir as possibilidades de má interpretação dos mesmos. pois alterações num ponto do programa poderiam produzir consequências importantes e não facilmente identificáveis noutros pontos do programa. e numa fase posterior na definição preocupa-se em como essas funcionalidades serão implementadas. reduzia significativamente essas características. A designação de metodologias estruturadas deriva da aplicação de um conjunto de princípios semelhante ao utilizado pelas linguagens de programação (o principio da decomposição funcional). Estas metodologias eram compostas por uma sequência de fases e atividades. No entanto. em que cada atividade tem que ser completada e finalizada antes que a atividade seguinte possa ser iniciada. A maioria destas metodologias adotaram o modelo em cascata.

é uma sequência de atividades.Departamento Informática da UBI Cap. e que desencadeia uma mudança de estado. a empresa confere a fatura que entretanto lhe foi sido enviada.2011/2012 Carlos Barrico . Estado de uma entidade . pode ou não autorizar o mesmo. e se tudo estiver correto. Repositório de dados . Engenharia de Software . que completa a encomenda. Evento . e que são relevantes para o desempenho adequado da função da organização. e o processo pára.representa toda a circulação (e o respetivo suporte) de informação que ocorre numa organização de forma a executar os processos de negócio.2011/2012 Carlos Barrico . a maioria concretizados em diversos diagramas. Este. bem como a(s) encomenda(s) que lhe deram origem (uma encomenda pode ser satisfeita de várias vezes). 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 30 As Metodologias Estruturadas – Contexto e Motivação As Metodologias Estruturadas – Conceitos Básicos Análise Orgânica. Após a última entrega. depois de analisar o pedido. atributos e relações existentes num determinado domínio do problema. desenvolvimento do sistema. que processam vários inputs e produzem vários outputs. A entrada dos bens ocorre sempre no armazém. onde é conferido o material recebido com a guia de remessa que o acompanha. e na identificação de relações entre esses grupos de informação. destacando-se os seguintes (comuns aos métodos orientados a processos e aos dados): Entidade . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 31 Cap. validação e classificação das entidades. entidades físicas ou abstratas. A atenção concentra-se nos dados. destacando-se os seguintes (exclusivos das abordagens orientadas a processos): Processo (de negócio) . Esta preocupação incide sobretudo na compreensão e no agrupamento de dados comuns.2011/2012 Carlos Barrico .todos os conceitos de negócio. ou pode representar simplesmente a passagem de tempo. Neste segundo caso. é emitido um meio de pagamento ao fornecedor (poderá ser em cheque ou por transferência bancária).representam os conceitos sobre os quais importa à organização reter informação para utilização futura. Fluxo de Informação . o requisitante recebe uma notificação.Departamento Informática da UBI Engenharia de Software . A análise de dados envolve a recolha.2011/2012 Carlos Barrico . Engenharia de Software .Departamento Informática da UBI Engenharia de Software . os conceitos principais devem permanecer e continuar a ser utilizados. Caso da gestão de compras de materiais de uma empresa (enunciado): Sempre que algum funcionário tem necessidade de comprar bens para as suas atividades. a maioria concretizados em diversos diagramas. este preenche uma requisição onde identifica os bens em questão (com base na consulta de uma lista anteriormente disponibilizada a todos os funcionários).é um acontecimento que é desencadeado interna ou externamente ao sistema. Cada processo pode ser subdividido em processos mais elementares até se atingir um nível que não é possível decompor mais. É uma definição muito semelhante à de processo de desenvolvimento de software. a qual envia para o seu diretor. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 29 Cap.Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 32 As Metodologias Estruturadas – Conceitos Básicos As Metodologias Estruturadas – Conceitos Básicos As metodologias estruturadas introduziram um conjunto de conceitos. internas ou externas à organização.é representado por um conjunto de valores que os atributos da entidade podem assumir.Departamento Informática da UBI . A ideia é que mesmo quando uma aplicação muda. relaciona-a com as encomendas respetivas. colocando os conceitos e as entidades manipuladas no negócio como os elementos mais importantes do As metodologias estruturadas introduziram um conjunto de conceitos. o requisitante preenche uma encomenda que envia para o fornecedor por ele selecionado. No caso do pedido ser aprovado. sem alterações significativas.

Dicionários de dados: são repositórios de definições de todos os elementos e conceitos utilizados e manipulados pela organização e respetivos sistemas de informação e que incluem entre outros os dados. ficheiros. em que o objetivo é descrever a evolução de uma entidade ao longo da sua existência. o requisitante recebe uma notificação. entidades externas. depois de analisar o pedido.2011/2012 Carlos Barrico . Engenharia de Software . onde identifica os bens em questão (com base na consulta de uma lista anteriormente disponibilizada a todos os funcionários). a qual envia para o seu diretor. que completa a encomenda. Diagramas entidade associação (entity relarionship diagram): São especificações gráficas que representam as relações estáticas de um sistema. o mais relevante no caso das metodologias estruturadas. e dos eventos que desencadeiam as transições entre estados. em que se identificam graficamente processos. normalmente. No caso do pedido ser aprovado. A entrada dos bens ocorre sempre no armazém. O diagrama de fluxo de dados de primeiro nível é nalgumas metodologias designado por diagrama de contexto. Engenharia de Software . fluxos de informação e repositórios de dados. a empresa confere a fatura que entretanto lhe foi sido enviada. pode ou não autorizar o mesmo.Departamento Informática da UBI O conceito de processo de negócio é. Este.2011/2012 Carlos Barrico . alterações significativas e eliminação do sistema. designadamente as entidades. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 34 As Metodologias Estruturadas – Conceitos Básicos As Metodologias Estruturadas – Conceitos Básicos Caso da gestão de compras de materiais de uma empresa (resolução): Sempre que algum funcionário tem necessidade de comprar bens para as suas atividades. com os seus atributos. e conduzem toda a análise e especificação posterior. processos e entidades. relaciona-a com as encomendas respetivas. Neste segundo caso.Departamento Informática da UBI . e o processo pára. e se tudo estiver correto. bem como a(s) encomenda(s) que lhe deram origem (uma encomenda pode ser satisfeita de várias vezes). o requisitante preenche uma encomenda que envia para o fornecedor por ele selecionado.Departamento Informática da UBI Cap. Tipos de notações propostas pelas metodologias estruturadas (cont): Diagrama de transição de estados (state transition diagram): É uma representação gráfica dos estados em que um sistema ou uma entidade se pode encontrar ao longo da sua existência. uma vez que existe a possibilidade de especificar um processo através de um diagrama de maior detalhe. é emitido um meio de pagamento ao fornecedor (poderá ser em cheque ou por transferência bancária). Podem ser construídos em vários níveis.Departamento Informática da UBI Engenharia de Software . Os processos são os primeiros a ser identificados.2011/2012 Carlos Barrico . designadamente as operações de criação. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 35 Cap. Engenharia de Software . São os principais diagramas utilizados na modelação de processos. onde é conferido o material recebido com a guia de remessa que o acompanha. e a forma como estas se encontram associadas. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 33 Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 36 As Metodologias Estruturadas – Técnicas e Notações mais usadas As Metodologias Estruturadas – Técnicas e Notações mais usadas Tipos de notações propostas pelas metodologias estruturadas: Diagramas de fluxo de dados (data flow diagram): São especificações orientadas aos processos. Após a última entrega.Cap. Diagrama do ciclo de vida de entidade (entity life cycle): consiste numa versão adaptada de um diagrama de estados.2011/2012 Carlos Barrico . este preenche uma requisição.

Departamento Informática da UBI Cap. aplicando um conjunto de regras designadas por formas normais do modelo relacional.Departamento Informática da UBI Engenharia de Software . permitem identificar que entidades intervêm em que processos. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 38 As Metodologias Estruturadas – Técnicas e Notações mais usadas As Metodologias Estruturadas – Técnicas e Notações mais usadas Tipos de notações propostas pelas metodologias estruturadas (cont): Matrizes entidade-processo: são matrizes que demonstram as relações existentes entre as entidades e os processos.2011/2012 Carlos Barrico . Por exemplo. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 39 Cap. conforme as metodologias de Yourdon e SSADM. SSADM Yourdon A figura seguinte representa o enunciado da gestão de compras através de um diagrama de fluxo de dados (notação de Yourdon): os processos (representados por ovais). na figura seguinte pode-se observar como o mesmo conceito “processo” é representado por símbolos gráficos distintos.2011/2012 Carlos Barrico .Departamento Informática da UBI .Cap.Departamento Informática da UBI Engenharia de Software . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 40 As Metodologias Estruturadas – Técnicas e Notações mais usadas As Metodologias Estruturadas – Técnicas e Notações mais usadas “Processo” representado segundo as notações de SSADM e Yourdon. Diagrama de fluxo de dados do problema de gestão de compras.2011/2012 Carlos Barrico . isto é. O elevado número de metodologias disponíveis no mercado fez com que a simbologia utilizada variasse normalmente conforme a metodologia adotada. os repositórios de dados (retângulos abertos lateralmente). as entidades intervenientes (retângulos). Engenharia de Software . Engenharia de Software . Fluxogramas: diagramas que expressam os passos de execução de algoritmos e processamentos realizados no sistema. cuja preocupação é eliminar redundâncias na estrutura de dados e garantir a integridade da informação. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 37 Cap. e os fluxos de informação (setas).2011/2012 Carlos Barrico . Normalização: consiste num processo de construção do esquema de uma base de dados a partir da lista de entidades e dos respetivos atributos.

e modularidade .Departamento Informática da UBI Engenharia de Software .2011/2012 Carlos Barrico . Na relação entre “requisições” e “encomendas”.Departamento Informática da UBI . a deteção da necessidade. a cardinalidade desta relação. e por esta ordem. o preenchimento da requisição. identificando as entidades sobre as quais interessa guardar informação. lê-se “uma requisição pode ser satisfeita por várias encomendas”. e implica a sua caracterização segundo dois conceitos adicionais: Esta informação seria também adequadamente representada por um cardinalidade .2011/2012 Carlos Barrico . Qualquer relação expressa num diagrama entidade associação pode ser sempre analisada na perspetiva de ambas as entidades intervenientes. Engenharia de Software . a consulta à lista de bens disponíveis. Por exemplo. o que permite identificar quais são obrigatórias ou opcionais. de nível mais detalhado. o respetivo detalhe poderia incluir. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 44 As Metodologias Estruturadas – Técnicas e Notações mais usadas As Metodologias Estruturadas – Técnicas e Notações mais usadas Diagrama entidade associação para o exemplo da gestão de compras. que apresenta a visão estática do sistema. Engenharia de Software . no caso do processo registo da requisição (1. representada pelos símbolos mais próximos de cada retângulo.número máximo de ocorrências de cada uma na relação. e o envio para o diretor. a modularidade pode ser lida “podemos ter uma requisição que não dá origem a nenhuma encomenda” (é o caso em que o diretor não aprova o pedido). 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 42 As Metodologias Estruturadas – Técnicas e Notações mais usadas As Metodologias Estruturadas – Técnicas e Notações mais usadas Poderíamos representar alguns processos com um nível de detalhe superior.Departamento Informática da UBI Engenharia de Software . Outro tipo de diagrama muito utilizado é o entidade-associação.número mínimo de ocorrências de cada uma.2011/2012 Carlos Barrico .1).Departamento Informática da UBI Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 41 Cap. bem como o respetivo relacionamento.Cap. e para isso já dispomos de informação no enunciado.2011/2012 Carlos Barrico . diagrama de fluxo de dados. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 43 Cap.

sendo deste modo possível demonstrar a correção da especificação.Departamento Informática da UBI Engenharia de Software . face às funcionalidades identificadas.é obtida através de diagramas de entidade associação (DEA) (3) a sua evolução ao longo do tempo – representada pelos diagramas de ciclos de vida de entidades. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 47 Cap. com o rigor e formalismo correspondentes. No entanto. é representada através de diagramas de fluxo de dados conhecidas que maior relevância e divulgação tiveram . Durante muito tempo (e ainda hoje) foi considerada a metodologia de referência e ensinada em diversos cursos universitários. No Reino Unido. e que deviam ser aplicadas na sua elaboração. Estas três visões são integradas. semiformais.Departamento Informática da UBI Engenharia de Software . foi durante muito tempo obrigatória a sua utilização em todos os projetos relacionados com o desenvolvimento de sistemas de informação a nível governamental. Engenharia de Software . estado inicial. os DFD são comparados com os DEA. operações). No sentido de resolver este problema. Engenharia de Software . funções de input e de output. estes diagramas não garantem nem demonstram a respetiva correção. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 45 Cap. definições de estado. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 48 As Metodologias Estruturadas – Principais Metodologias As Metodologias Estruturadas – Principais Metodologias Das muitas metodologias propostas para o desenvolvimento de software. com simbologia e conceitos matemáticos e lógica de primeira ordem (conjuntos. e alvo de sucessivas revisões. apenas se vão referir as metodologias estruturadas SSADM A modelação de um sistema segundo três perspetivas complementares: (1) a sua funcionalidade (DFD) (2) a sua estrutura . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 46 As Metodologias Estruturadas – Técnicas e Notações mais usadas As Metodologias Estruturadas – Técnicas e Notações mais usadas Os diagramas apresentados incluem-se no grupo das notações Algumas notações mais conhecidas são: Redes de Petri: diagramas particularmente adequados para a representação de sistemas com problemas de concorrência e com restrições a nível de sincronização.2011/2012 Carlos Barrico .Departamento Informática da UBI .2011/2012 Carlos Barrico .Departamento Informática da UBI Cap. Linguagem Z: linguagem de especificação formal. SSADM (Structured Systems Analysis and Design Methodology). de forma a garantir que cada entidade referida num DEA é criada por algum processo especificado num DFD. constantes. foram propostas notações formais.Cap. Proposta por Learmonth (1981). tipos de dados. utiliza conceitos como transições.2011/2012 Carlos Barrico . por exemplo. que se caracterizam por adotar conceitos muito próximos da matemática. uma vez que tinham um conjunto de regras associadas.2011/2012 Carlos Barrico .

Departamento Informática da UBI Cap.Cap. Engenharia de Software . Não é fácil identificar quem fez o quê. Engenharia de Software . Permanece a dificuldade de lidar com alterações aos requisitos.2011/2012 Carlos Barrico . (3) desenho de sistemas. A qualidade do software é baixa e o seu desempenho inadequado. o que é expresso nos diferentes estágios de evolução do processo designadamente: (1) planeamento estratégico dos sistemas de informação. Os erros de conceção são descobertos tardiamente. A especificação lógica do sistema. A sequência de atividades envolve: A realização de um estudo de viabilidade. mas também atribui uma importância significativa à estrutura dos dados.Departamento Informática da UBI Engenharia de Software . e (4) implementação.2011/2012 Carlos Barrico . revista em 1993). As suas raízes estão no trabalho originalmente desenvolvido pela IBM na sua metodologia Business Systems Planning. Yourdon Systems Method (proposta por Yourdon. (2) análise de áreas do negócio. e suportada essencialmente pela utilização de diagramas de fluxos de dados. A especificação dos mesmos requisitos. Não é fácil a integração e reutilização de módulos e componentes do sistema. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 50 As Metodologias Estruturadas – Principais Metodologias As Metodologias Estruturadas – Principais Metodologias SSADM É uma metodologia concebida sobretudo para a análise e desenho do sistema.Departamento Informática da UBI . é semelhante à STRADIS pois recorre muito à decomposição funcional. testes e instalação do mesmo. baseada na filosofia de decomposição funcional top-down. de modo a determinar a forma como os requisitos identificados são implementados.Departamento Informática da UBI STRADIS (Structured Analysis. modelos e técnicas das metodologias estruturadas e do desenvolvimento de software dos anos 1980 numa abordagem coerente a todas as atividades do processo de Alguns problemas das técnicas e metodologias estruturadas descritas: Não conseguem lidar adequadamente com o problema da complexidade e do tamanho crescente dos sistemas. Tem uma preocupação estratégica com a definição dos sistemas de informação. Integra diversas notações orientadas para a modelação quer dos processos quer dos dados.2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 51 Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 49 Cap. de modo a avaliar até que ponto o sistema tem custos aceitáveis. por parte dos intervenientes técnicos. O desenho físico do sistema. Não resolvem o problema da crescente atividade de manutenção do software.2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 52 As Metodologias Estruturadas – Principais Metodologias Metodologias Orientadas por Objetos Engenharia de Informação (proposta por James Martin em 1989) integra muitos dos conceitos. Verifica-se com frequência a má compreensão dos requisitos do utilizador. Design and Implementation of Information Systems). desenvolvimento de software. melhores práticas. desenvolvida por Gane e Sarson em finais da década de 1970. não contemplando as tarefas relacionadas com a implementação. Engenharia de Software . quando e porquê. A análise de requisitos do negócio.

A orientação por objetos. A definição exata de orientação por objetos não é única. classificação. com base nas diferenças e semelhanças existentes ao nível das características e comportamento dos mesmos objetos. se bem que em termos práticos tenha sido primeiramente concretizada ao nível das linguagens de programação. o paradigma da orientação por objetos resulta da convergência de quatro outros conceitos: objetos. Engenharia de Software . As metodologias orientadas por objetos são abordagens mais naturais do que as baseadas em processos e dados. uma vez que o mesmo conceito base é utilizado ao longo de todas as fases do processo.Departamento Informática da UBI Engenharia de Software . reutilização de código. Desde o início dos anos 1970 que três ideias independentes ganharam importância. O conceito da orientação por objetos baseia-se numa nova forma de analisar o mundo. e facilitando a manutenção. com o objetivo de facilitar todo o processo de desenvolvimento de software. não tem impacto apenas a esse nível. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 53 Cap.2011/2012 Carlos Barrico .Departamento Informática da UBI . e visão do mundo (e posterior modelação) segundo um conjunto de objetos. e os conceitos básicos são simples e reproduzem o mundo real. pois “reproduz” a forma como o ser humano se apercebe e expressa a realidade que o rodeia. a perspetiva de modelação dos sistemas muda. As técnicas orientadas por objetos identificam e definem cada objeto de modo a reutilizá-lo.Contexto e Motivação Nas abordagens orientadas por objetos.Departamento Informática da UBI Cap.2011/2012 Carlos Barrico . e que em última análise estão na base da estrutura de conceitos do paradigma da orientação por objetos: encapsulamento de informação. da mesma forma que o ser humano acumula conhecimento com base no previamente adquirido.2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 55 Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 56 Metodologias Orientadas por Objetos Metodologias Orientadas por Objetos . herança e comunicação por mensagens. Para Coad e Yourdon (1991). promovendo a reutilização e o encapsulamento da informação. e não segundo uma perspetiva funcional. Engenharia de Software .2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 54 Metodologias Orientadas por Objetos Metodologias Orientadas por Objetos A aplicação de diversas das melhores práticas atuais de engenharia de software veio solucionar algumas destas questões e esteve na origem do conceito da orientação por objetos. que estava vocacionada para a implementação de sistemas de simulação. O ser humano classifica e subdivide o mundo em diferentes objetos.Departamento Informática da UBI Engenharia de Software .Cap. As raízes da engenharia de software orientada por objetos podem ser encontradas num trabalho desenvolvido na linguagem Simula em finais dos anos 1960.

3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 57 Cap. Engenharia de Software . a linguagem Smalltalk (Goldberg. Construir especificações capazes de resistir à mudança.2011/2012 Carlos Barrico . 1989).Departamento Informática da UBI Cap. Engenharia de Software . Coad e Yourdon (1991) identificaram as motivações principais para a realização de atividades de análise segundo o paradigma da orientação por objetos: Poder tratar domínios de problemas mais complexos.Cap.Departamento Informática da UBI Engenharia de Software .2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 59 Cap. No entanto. e Abstração. Melhorar a interação entre o analista e o especialista do problema. Reutilizar resultados da análise.Departamento Informática da UBI . e (2) as restantes noções base. Polimorfismo.Contexto e Motivação Metodologias Orientadas por Objetos . Conceber uma representação consistente para a análise e desenho.Contexto e Motivação Estes três conceitos estão na base da primeira linguagem classificada como verdadeiramente suportando este paradigma. Aumentar a consistência interna dos resultados da análise. Representar explicitamente aspetos comuns a diversos conceitos.Departamento Informática da UBI Engenharia de Software .2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 58 Metodologias Orientadas por Objetos . que constituem um conjunto de ideias base de todo o paradigma. criada nos laboratórios PARC da Xerox. e alguns deles são mesmo os requisitos necessários para um sistema ser considerado orientado por objetos. comuns a todos os sistemas orientados por objetos. Herança. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 60 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Nas abordagens orientadas por objetos distinguem-se essencialmente dois grandes grupos de conceitos: (1) os princípios. a maioria das iniciativas relacionadas com o paradigma da orientação por objetos situava-se ao nível da programação.2011/2012 Carlos Barrico . Princípios Orientadores do Paradigma Encapsulamento da informação. e até meados da década de 1980.

Engenharia de Software .Departamento Informática da UBI . enquanto os métodos orientados por objetos utilizam objetos.Cap. acrescenta ou redefine operações e atributos a partir de uma ou mais superclasses. permitindo adicionalmente acrescentar detalhes específicos. através da disponibilização de uma interface pública. É utilizada em situações em que uma operação é partilhada na maior parte dos casos. Esta característica permite a criação de objetos estáveis e reutilizáveis. incidindo sobre as características essenciais do objeto. Este termo aparece associado às noções de generalização e de especialização. Pode ser encarado como a localização de funcionalidades numa única abstração autocontida.Departamento Informática da UBI Cap. O conjunto de operações que são acessíveis do exterior constitui a interface do objeto. É uma forma de aumentar a reutilização do que é comum. nem para a disponibilização de funcionalidades para o seu exterior. Abstração É a representação concisa duma ideia ou objeto mais complexa. Outra forma de definir esta propriedade é dizer que ela representa a capacidade de objetos diferentes responderem de forma diferente à mesma mensagem.2011/2012 Carlos Barrico . Tal é concretizado pelo facto de uma operação aceitar argumentos de tipos diferentes ou mesmo desconhecidos. uma subclasse é uma especialização de uma ou mais superclasses.Departamento Informática da UBI Engenharia de Software .2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 62 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Encapsulamento da informação É o processo de “esconder” todos os detalhes de um objeto que não contribuem para as suas características essenciais. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 63 Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 61 Cap.2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 64 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Polimorfismo É a capacidade de “esconder” várias implementações distintas através de uma única interface. Herança Representa a definição de relações entre classes através da qual uma subclasse partilha.2011/2012 Carlos Barrico . que esconde a respetiva implementação e decisões de desenho. mas em que pelo menos uma subclasse necessita de uma versão específica. Engenharia de Software . As abordagens tradicionais concretizam esta ideia pelas abstrações funcionais (processos).Departamento Informática da UBI Engenharia de Software . reproduzindo o mundo real de forma correta.

Engenharia de Software .propriedade que distingue um objeto ativo de um outro não ativo.2011/2012 Carlos Barrico .Departamento Informática da UBI Cap. O conceito de classe.decomposição lógica e física de conceitos em unidades mais elementares. abstração ou coisa com fronteiras bem definidas e com significado para o problema em questão. Rumbaugh (1991): um objeto é um conceito. existem outras noções importantes: Modularidade .Departamento Informática da UBI Engenharia de Software . que pertence ao domínio da solução. Persistência . Engenharia de Software . de forma a facilitar a aplicação dos princípios da engenharia de software. Engenharia de Software . As linguagens que não suportam as noções de herança e/ou Outros Conceitos Chave do Paradigma da Orientação por Objetos Existem outros conceitos que são fundamentais para a compreensão do paradigma da orientação por objetos. Cada objeto tem uma ou mais operações. o conceito de objeto. refletindo a capacidade do sistema de manter informação sobre ele e de interagir com ele. Booch (1994): algo ao qual se pode fazer qualquer coisa. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 66 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Estes quatro princípios são considerados necessários e suficientes para considerar uma linguagem como sendo orientada por objetos. Object Management Group: um objeto é uma coisa. Cada objeto tem uma identidade única distinta e independente de quaisquer das suas características. Para além destes princípios.Departamento Informática da UBI Objeto: praticamente cada metodologia e respetivo autor apresentam definições próprias (cont) : Coad e Yourdon (1991): uma abstração de qualquer coisa no domínio de um problema. criada como uma instância de um tipo de objetos. Berard (1993): objetos são as entidades reais ou conceptuais que podem ser encontradas no mundo que nos rodeia.2011/2012 Carlos Barrico .2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 68 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Objeto: praticamente cada metodologia e respetivo autor apresentam definições próprias: Firesmith (1996): um objeto pode ser definido como uma abstração de software que modela todos os aspetos relevantes de uma única entidade conceptual ou tangível.Cap.Departamento Informática da UBI . Shlaer e Mellor (1988): um objeto é uma abstração de um conjunto de coisas do mundo real de tal forma que todos os elementos do conjunto (instâncias) têm as mesmas características e respeitam as mesmas regras e políticas. para além de outros que estão diretamente relacionados com estes. tem estado. Concorrência .2011/2012 Carlos Barrico . é um encapsulamento de valores de atributos e dos seus serviços exclusivos.propriedade de um objeto através da qual a sua existência perdura no tempo e/ou no espaço. promove a reutilização e funciona como uma base concreta para a respetiva implementação em software. polimorfismo são normalmente designadas por “baseadas em objetos”. comportamento e identidade. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 67 Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 65 Cap.

2011/2012 Carlos Barrico . locais geográficos. ou apenas necessárias para a representação em computador (por exemplo. Engenharia de Software . os objetos representam entidades físicas. independentemente do problema a solucionar: Coad e Yourdon: estruturas. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 71 Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 70 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Resumidamente. um objeto pode ser um conceito. funções de pessoas. Conceptuais. estruturas de dados). funções desempenhadas. e identidade. independentemente do problema a solucionar: Shlaer e Mellor: entidades e coisas tangíveis. Comportamento de um objeto É o conjunto de ações que um objeto pode realizar de forma independente. interações. Comportamento. implementam um serviço e/ou funcionalidade que pode ser requerido por qualquer objeto que faça parte do universo do problema. ao nível da programação o termo método refere-se à implementação de uma operação.2011/2012 Carlos Barrico . outros sistemas. um objeto tem estado. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 69 Cap.Cap.Departamento Informática da UBI Engenharia de Software . organizações. Normalmente existem dois termos para referir os mecanismos utilizados para implementar este conceito: ao nível da análise o termo mais utilizado é o de operação ou serviço.2011/2012 Carlos Barrico . coisas ou acontecimentos memorizados. e unidades organizacionais. e especificações. Alguns autores enumeram as fontes onde pesquisar os possíveis candidatos a objetos. incidentes. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 72 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Alguns autores enumeram as fontes onde pesquisar os possíveis Outros Conceitos Chave do Paradigma da Orientação por Objetos Atributos São propriedades nomeadas de um objeto que indicam os valores possíveis que esse atributo pode assumir ao longo do tempo.Departamento Informática da UBI Cap. A maioria das operações realizadas responde a perguntas ou alteram o estado do objeto.Departamento Informática da UBI .2011/2012 Carlos Barrico . O estado de um objeto é definido pelo valor dos seus atributos. Engenharia de Software . eventos. Na prática. candidatos a objetos. e de forma a integrar as diversas definições. uma abstração. dispositivos.Departamento Informática da UBI Engenharia de Software . procedimentos operacionais. com fronteiras bem definidas e que tem um significado para um problema e respetiva solução. ou uma entidade.

Engenharia de Software . as unidades de medida.2011/2012 Carlos Barrico . e eventuais condições relacionadas com outros atributos do objeto ou classe.Departamento Informática da UBI Cap.Departamento Informática da UBI . A interface e os serviços de cada classe. Cada metodologia propõe diferentes formas de chegar a esta informação. ou uma fábrica. As diversas relações entre classes.2011/2012 Carlos Barrico . Pode ser vista como um template para um determinado objeto e todos os que lhe forem semelhantes. Por exemplo. e normalmente referem alguns critérios.Departamento Informática da UBI Engenharia de Software . É uma das concretizações do conceito abstração no paradigma da orientação por objetos. e relações comuns. o valor inicial. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 75 Cap. a análise orientada por objetos procura identificar os objetos concretos e as respetivas classes. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 73 Cap. Coad (1991) indica um conjunto de questões a colocar. comportamento (operações). definir o estado da classe. O seu objetivo último será sempre identificar: Um conjunto de classes que representem totalmente o domínio do problema. em geral. identificar a classe.Departamento Informática da UBI Engenharia de Software . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 76 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Dado um enunciado de um problema. reter alguma informação sobre a classe. Para especificar detalhadamente um atributo deve-se identificar o domínio dos seus valores. as condições de leitura e escrita. que produz tantos objetos idênticos quanto necessário. o valor por omissão.Cap. Objetos concretos que seja necessário particularizar.2011/2012 Carlos Barrico . a partir de todos os substantivos que dele sejam extraídos. e identificar o comportamento do objeto. definir as características especiais da classe.2011/2012 Carlos Barrico . Os atributos permitem. de modo a averiguar se um substantivo do enunciado constitui um objeto ou uma classe: A informação sobre o objeto tem que ser retida de modo a que o sistema funcione adequadamente? O objeto realiza operações que alteram atributos de outros objetos? O objeto tem mais do que um atributo? Outros objetos aparentemente idênticos disponibilizam operações idênticas? O objeto produz ou consome informação essencial para o funcionamento do sistema? Engenharia de Software . Os atributos de cada classe. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 74 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Classe É um descrição de grupos de objetos com propriedades (atributos).

que completa a encomenda. Iterador . bem como a(s) encomenda(s) que lhe deram origem (uma encomenda pode ser satisfeita de várias vezes). Neste segundo caso. o requisitante preenche uma encomenda que envia para o fornecedor por ele selecionado. No enunciado da gestão de compras. relaciona-a com as encomendas respetivas. o requisitante recebe uma notificação. relaciona-a com as encomendas respetivas. A entrada dos bens ocorre sempre no armazém.2011/2012 Carlos Barrico .Departamento Informática da UBI Cap. Neste segundo caso. onde é conferido o material recebido com a guia de remessa que o acompanha.Departamento Informática da UBI Engenharia de Software . a qual envia para o seu diretor. pode ou não autorizar o mesmo.2011/2012 Carlos Barrico . No caso do pedido ser aprovado. que completa a encomenda. a empresa confere a fatura que entretanto lhe foi sido enviada. pode ou não autorizar o mesmo. Engenharia de Software . Seletor . o requisitante recebe uma notificação. depois de analisar o pedido. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 78 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Noutras situações. Este. composta por operações e por atributos. e aos conceitos base fundamentais que lhes estão subjacentes (objetos em vez de processos). 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 79 Cap. onde é conferido o material recebido com a guia de remessa que o acompanha. e o processo pára. Essas operações podem ser agrupadas nas seguintes categorias: Modificador .Cap.operação que altera o estado de um objeto. e se tudo estiver correto. são indicadas checklists de circunstâncias em que um potencial objeto não o deve ser. depois de analisar o pedido. Este.2011/2012 Carlos Barrico . No caso do pedido ser aprovado. Objetos ou classes que de facto correspondem a atributos de outros objetos. por exemplo: Objetos ou classes com apenas um atributo. O acesso aos objetos é efetuado através da interface por eles disponibilizada. este preenche uma requisição onde identifica os bens em questão (com base na consulta de uma lista anteriormente disponibilizada a todos os funcionários). Objetos ou classes que não sejam relevantes para a solução do problema.Departamento Informática da UBI . é emitido um meio de pagamento ao fornecedor (poderá ser em cheque ou por transferência bancária). A entrada dos bens ocorre sempre no armazém.“escondem” os detalhes da sua implementação aos objetos que a utilizam.cria um objeto e/ou inicializa o seu estado. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 77 Cap. Após a última entrega. a qual envia para o seu diretor. Classes com apenas um objeto. devido à mudança de paradigma. o requisitante preenche uma encomenda que envia para o fornecedor por ele selecionado. e o processo pára. Destrutor .operação que acede ao estado de um objeto.operação que permite que todas as partes de um objeto sejam acedidas segundo uma ordem bem definida.2011/2012 Carlos Barrico . nota-se que a pesquisa passa a incidir sobre outras palavras (substantivos em vez de verbos). este preenche uma requisição onde identifica os bens em questão (com base na consulta de uma lista anteriormente disponibilizada a todos os funcionários). Engenharia de Software . e se tudo estiver correto. Após a última entrega. a empresa confere a fatura que entretanto lhe foi sido enviada. Caso da gestão de compras de materiais de uma empresa (enunciado): Sempre que algum funcionário tem necessidade de comprar bens para as suas atividades.liberta o estado de um objeto ou destrói-o. ou que não produzem um resultado visível para o problema em análise. bem como a(s) encomenda(s) que lhe deram origem (uma encomenda pode ser satisfeita de várias vezes). Construtor . Engenharia de Software . Objetos ou classes sem serviços aplicáveis. Os objetos funcionam como caixas negras . é emitido um meio de pagamento ao fornecedor (poderá ser em cheque ou por transferência bancária). 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 80 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos (Outros Conceitos Chave) Caso da gestão de compras de materiais de uma empresa (resolução): Sempre que algum funcionário tem necessidade de comprar bens para as suas atividades.Departamento Informática da UBI As operações realizadas por objetos podem ser identificadas pela pesquisa no enunciado de verbos associados a cada objeto.

traduzido nos valores que os seus atributos assumem.2011/2012 Carlos Barrico . o mesmo método executado com os mesmos parâmetros sobre objetos diferentes. mas ambos instâncias da mesma classe.faz parte da interface mas não é visível para nenhuma outra classe do sistema.Cap.Departamento Informática da UBI Engenharia de Software . no contexto do objeto recetor da mensagem.só visível pelas suas subclasses.2011/2012 Carlos Barrico . Por isso. e privada . este modelo é a invocação de uma função.Departamento Informática da UBI Engenharia de Software . Na prática. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 82 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Os objetos comunicam entre si por mensagens.2011/2012 Carlos Barrico . Visibilidade de métodos da interface. que são a invocação de um método com o mesmo nome.Departamento Informática da UBI . só está disponível na implementação da própria classe.2011/2012 Carlos Barrico . A figura seguinte apresenta o modelo de comunicação entre objetos por mensagens. protegida . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 83 Cap. tal como nas abordagens tradicionais. Engenharia de Software .visível para todos os objetos do sistema.Departamento Informática da UBI Cap. Engenharia de Software . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 81 Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 84 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos A interface é o conjunto de operações e atributos disponibilizados por uma classe e pode dividir-se em três partes (consoante a visibilidade): pública . pode produzir resultados diferentes. A diferença é que esta invocação é realizada no contexto de um objeto. o que significa que tem em conta o seu estado.

outras notações para os conceitos dinâmicos interações. mudanças de estado. Engenharia de Software . uma concretização desta relação é dizer que “o corpo humano tem uma perna”. Diagrama de classes. Composição: forma de agregação em que a relação de pertença é forte e com tempos coincidentes. Diagramas de interação. e Exemplo: um automóvel (para andar) precisa de se abastecer na bomba de gasolina. Diagrama de contexto. sendo as principais (quase todas presentes na Rational e na linguagem UML) as seguintes: Diagrama de casos de uso/utilização. como no caso “um cão é um animal”. Engenharia de Software . Diagrama de atividades.Cap. e Diagrama de fluxo de dados. sequências de ações. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 87 Cap. Diagrama de estados. Engenharia de Software .2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 86 Metodologias Orientadas por Objetos – Conceitos Básicos Metodologias Orientadas por Objetos – Conceitos Básicos Entre as diversas classes de um sistema podem ser estabelecidas diferentes tipos de relações: Associação: representam relações estruturais entre objetos de classes diferentes. Generalização/Especialização: relações entre classes que partilham a estrutura e comportamento.2011/2012 Carlos Barrico . que pode ser simples (uma classe tem apenas uma superclasse) ou múltipla (uma classe pode ter várias superclasses). esta relação é expressa pelo verbo ser.Departamento Informática da UBI Independentemente do nome dos diagramas utilizados por cada metodologia. Agregação: é a conhecida relação entre o todo e as partes (whole-part). cada uma apresenta notações para modelar a visão estática do sistema: a estrutura dos objetos. e cuja informação tem que ser preservada durante algum tempo.Departamento Informática da UBI Algumas abordagens procuram definir conceitos que permitem agrupar classes: assunto (Coad e Yourdon).2011/2012 Carlos Barrico . Engenharia de Software . e mecanismos de temporização. pacote (UML). Diagrama de pacotes. Entre as diversas classes de um sistema podem ser estabelecidas diferentes tipos de relações (cont): Dependência: relação em que uma mudança de estado num objeto (ocorrida pela receção de uma mensagem) pode implicar o envio de uma mensagem a outro objeto.Departamento Informática da UBI Cap. Diagrama de eventos. é expressa pelo verbo ter.2011/2012 Carlos Barrico . um exemplo possível é a relação “uma empresa tem empregados”. as relações de agregação e de especialização. CRC (Class-Relationship-Collaboiration) cards.Departamento Informática da UBI . implementam o conceito de herança. o objeto agregador é responsável pela criação e destruição do objeto que entra na sua composição. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 85 Cap. e a comunicação entre objetos). 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 88 Metodologias Orientadas por Objetos – Técnicas e Notações mais Utilizadas Metodologias Orientadas por Objetos – Técnicas e Notações mais Utilizadas A proliferação destas metodologias levou ao aparecimento de diversas notações e técnicas de modelação.

quer pela sua utilização quer pela relevância dos conceitos abordados. Definir uma estrutura de relações generalização-especificação.2011/2012 Carlos Barrico . Definir os atributos. dinâmico (apresentava o comportamento dos objetos e do sistema global) e funcional (diagrama de fluxo de informação no sistema semelhante aos diagramas de fluxos de dados). e determinação das relações entre classes.Departamento Informática da UBI Engenharia de Software . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 89 Cap. às quais aplicou técnicas orientadas por objetos.Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 90 Metodologias Orientadas por Objetos – Principais Metodologias Metodologias Orientadas por Objetos – Principais Metodologias Ao longo das décadas de 1980 e de 1990 surgiram inúmeras propostas de metodologias. Algumas das metodologias mais significativas. e respetivas características.2011/2012 Carlos Barrico .2011/2012 Carlos Barrico . Engenharia de Software . a hierarquia e outras relações).Departamento Informática da UBI Engenharia de Software . são as seguintes: Método de Booch OOSE (Object Oriented Software Engineering) OMT (Object Modelling Technique) OOAD (Object Oriented Analysis and Design) Método de Wirfs-Brock Método de Booch (proposto por Grady Booch em 1991) Baseia-se na ideia da repetição de atividades de um processo de desenvolvimento de modo a refinar o modelo em sucessivas iterações.Departamento Informática da UBI . sobretudo concentradas nas tarefas de análise e desenho. Definir uma estrutura de relações de associação (whole-part). 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 91 Cap. Definir os serviços. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 92 Metodologias Orientadas por Objetos – Principais Metodologias Metodologias Orientadas por Objetos – Principais Metodologias OMT (proposto por James Rumbaugh em 1991) Concentrou as suas propostas na análise e desenho de software. As suas principais atividades estão orientadas para a identificação de classes e objetos. OOAD (proposto por Coad e Yourdon em 1991) apresentava como uma das suas principais vantagens o facto de ser muito simples (ao nível dos conceitos. atividades e diagramas) o que o tornava um dos mais fáceis de compreender. As suas principais atividades relacionadas com a análise são no fundo aquilo que todos esperavam realizar num processo que aplicasse as noções da orientação por objetos: Identificar objetos utilizando critérios simples (substantivos). Identificar assuntos (subsistemas). utilizando os conceitos relacionados com o paradigma da orientação por objetos. Engenharia de Software .2011/2012 Carlos Barrico . OOSE (proposto por Ivar Jacobson em 1992) Resulta da evolução do modelo Objectory (também do mesmo autor) e a sua maior contribuição foi a introdução da noção de caso de utilização que funciona como uma descrição da interação entre o utilizador e o sistema. objetos. A sua metodologia apresentava essencialmente três modelos principais: estático ou de objetos (onde representam classes.Departamento Informática da UBI Cap.

a sua interface e as relações entre elas. e concentram-se na satisfação das necessidades das pessoas (informáticos e utilizadores).Departamento Informática da UBI Engenharia de Software . Apesar dos benefícios reconhecidos na utilização de metodologias (independentemente do paradigma utilizado). o código fonte das aplicações desenvolvidas. extrair classes candidatas por análise da especificação. Ferramentas que suportam a metodologia difíceis de utilizar. e reforçam a importância da atividade de testes. e construir representações hierárquicas das classes. Rigidez na aplicação dos métodos e conceitos.Cap. Estes métodos São bastante adaptáveis. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 93 Cap. Partilham a ideia do desenvolvimento iterativo típico das abordagens orientadas por objetos. DSDM . Algumas referências relevantes nesta área são as abordagens XP .Departamento Informática da UBI Cap. Feature Driven Development (Coad. Desconhecimento global da metodologia e falta de competências dos informáticos para a sua execução com qualidade. A produção de muito menos documentação por comparação com as metodologias estruturadas ou orientadas por objetos.Departamento Informática da UBI .Departamento Informática da UBI Engenharia de Software . Comungam a ideia de que as principais atividades a realizar ao longo de todo o processo de desenvolvimento são essencialmente a programação e os testes.Extreme Programming (Beck. Tempo que decorre até à disponibilização dos resultados finais. 1999). menor importância aos objetivos futuros. identificar colaborações entre classes com base nas responsabilidades. Defendem que a principal documentação de um sistema é. identificar grupos de classes (superclasses). Constatação da ausência de melhorias significativas no processo e produto final.2011/2012 Carlos Barrico .2011/2012 Carlos Barrico . Muitas destas novas metodologias advogam A não realização de atividades de análise e desenho. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 95 Cap. Engenharia de Software . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 94 Metodologias Orientadas por Objetos – Principais Metodologias Outras Metodologias Método de Wirfs-Brock não efetua uma distinção clara entre análise e desenho.Dynamic System Development Method. que implicam um nível de formalismo muito menor. e a sua principal contribuição foi a definição de um diagrama designado por CRC cards (Class-Responsibility-Colaboration) que procura identificar as classes do sistema. ou deveria ser. elas não estão isentas de críticas e de aspetos menos positivos: Complexidade nos conceitos. pois respondem à imprevisibilidade dos requisitos ao longo do tempo.2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 96 Outras Metodologias Outras Metodologias Desta forma. identificar relações entre classes. Engenharia de Software . definir e atribuir responsabilidades para cada classe. um novo grupo de metodologias começou a aparecer nos últimos anos. As principais atividades consistem em avaliar a especificação do cliente. e não na definição de processos. Concentração na análise da situação atual.2011/2012 Carlos Barrico . técnicas e aplicação. 1999).

outras incluem técnicas e notações). Muitas metodologias assumem um contexto de aplicação onde não existem os problemas que no mundo real têm que enfrentar. A comparação entre metodologias tem que considerar obrigatoriamente apenas um subconjunto das mesmas. A própria definição do conceito metodologia pode ser limitativa. em resultado das diversas características anteriormente enumeradas. A abrangência das metodologias varia fortemente (algumas apenas Noutras situações será preferível um processo mais formal.2011/2012 Carlos Barrico . em que os programadores são responsáveis. Muitas metodologias são influenciadas ou particularmente concebidas para serem utilizadas com linguagens de programação específicas. o conceito unificador agrega as duas visões. como: Não existem metodologias iguais e portanto em qualquer comparação estaremos sempre a comparar conceitos por vezes não comparáveis. o que potencia o aumento de produtividade dos informáticos. os clientes são igualmente participativos e responsáveis. sobretudo se estivermos a falar de sistemas pequenos ou com requisitos incertos ou voláteis. O sistema construído é consequentemente mais estável. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 100 Comparação de Metodologias Comparação de Metodologias Vantagens (em termos conceptuais) das abordagens orientadas por objetos face às estruturadas: Um único paradigma consistente ao longo de todo o processo. Alguns aspetos concretos em como as abordagens orientadas por objetos se revelam mais adequadas que as estruturadas: Gestão de Requisitos e Facilidade de Manutenção. nomeadamente sempre que o projeto exigir a alocação de equipas de maior dimensão. A facilidade de realização das tarefas de manutenção é maior. existir um contrato com âmbito e preços fixos. e um subconjunto de funcionalidades.Departamento Informática da UBI Cap.2011/2012 Carlos Barrico . Só recentemente começaram a surgir no mercado ferramentas de apoio ao processo de desenvolvimento segundo o paradigma da orientação por objetos. Representação da Realidade. experientes e encontram-se motivados. ou ainda quando a equipa de desenvolvimento é relativamente reduzida e estável. ou o risco seja elevado e o processo de controle do projeto deva ser reforçado. Engenharia de Software . Facilitam a reutilização do código e da arquitetura global do sistema. Engenharia de Software . Outros Aspetos. uma vez que a maioria dos informáticos continua a pensar em termos funcionais.2011/2012 Carlos Barrico . Não existe separação entre dados e processos.Cap.Departamento Informática da UBI . Apresentam modelos que refletem mais adequadamente o mundo real. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 98 Outras Metodologias Comparação de Metodologias Em determinadas circunstâncias estes métodos são particularmente aconselháveis. descrevem um processo. mais próximo do processo cognitivo humano. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 99 Cap.2011/2012 Carlos Barrico . Engenharia de Software .Departamento Informática da UBI Engenharia de Software . Os detalhes de implementação são escondidos do exterior pela aplicação de técnicas de encapsulamento da informação. A comparação das metodologias existentes é uma tarefa complexa devido a um conjunto de dificuldades que se colocam.Departamento Informática da UBI Problemas das abordagens orientadas por objetos: Nem sempre é fácil encontrar os objetos e classes apropriados no domínio do problema. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 97 Cap.

O sistema corresponde a uma malha de interdependências entre objetos. de forma mais ou menos independente. etc. Caso essa alteração não implicasse a alteração da interface providenciada pelo objeto. No desenvolvimento orientado por objetos. estruturado vs. O sistema corresponde a uma malha arbitrária de inúmeras Desenvolvimento objetos. Engenharia de Software . desenvolvimento orientado por interdependências entre funções e dados. e. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 102 Comparação de Metodologias .2011/2012 Carlos Barrico . os objetos apresentam dados e comportamento.Gestão de Requisitos e Facilidade de Manutenção No desenvolvimento estruturado. Dados e funções são agregados conjuntamente numa entidade lógica (o objeto) que providencia uma interface bem definida para outros objetos comunicarem com ele. O sistema consiste num conjunto de dados que são usados (em leitura e/ou escrita) por inúmeras funções. Engenharia de Software .Representação da Realidade As abordagens orientadas por objetos facilitam significativamente a gestão das alterações de requisitos. não haveria mais nada a fazer! Nas abordagens orientada por objetos. Uma alteração dos dados pode implicar a alteração de inúmeros fragmentos de código Impacto restrito na alteração de dados e código. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 103 Cap.Departamento Informática da UBI Engenharia de Software .Gestão de Requisitos e Facilidade de Manutenção Comparação de Metodologias . na pior das situações. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 104 Comparação de Metodologias . reutilização.Gestão de Requisitos e Facilidade de Manutenção Comparação de Metodologias . Manutenção mais fáceis. apenas seria necessário alterar a estrutura de dados que supostamente era definida no contexto interno de um determinado objeto..Departamento Informática da UBI . Nas abordagens orientadas por objetos. seria necessário adaptar consistentemente todas as funções que acedessem à estrutura de dados envolvida.Departamento Informática da UBI Engenharia de Software . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 101 Cap.Departamento Informática da UBI Cap. Imagine-se as implicações que a alteração da estrutura dos dados implica em ambas as abordagens. bem como identidade própria.2011/2012 Carlos Barrico .2011/2012 Carlos Barrico . a todas as funções que dependessem funcionalmente dessas primeiras funções. Na abordagem estruturada. etc.2011/2012 Carlos Barrico . uma conta bancária é um objeto do tipo “conta bancária”. Tal como as entidades do mundo real.Cap. as entidades do mundo real são captadas diretamente por objetos: um carro é um objeto do tipo “carro”.

reduzindo o custo de novas versões. Reduz o custo de alteração do sistema. não tem muito sentido usar-se uma linguagem orientada por objetos a seguir a um ciclo de análise e desenho tradicional. uma conta bancária pode ser Especialização de contas bancárias na abordagem OO. A orientação por objetos deve ser utilizada em todas as fases do ciclo de vida do software. reduzindo o custo de aprendizagem. Nestas abordagens.2011/2012 Carlos Barrico .Representação da Realidade Nas abordagens estruturadas. pela promoção da reutilização e encapsulamento de software. resumidamente: Providencia blocos de construção de alto nível que reduzem os custos de desenvolvimento. Por exemplo. alternativamente. Engenharia de Software . representada através de um ou mais módulos com funções específicas que acedem a várias estruturas de dados de forma independente. É difícil explicitar especializações ou generalizações correspondentes a conceitos inerentes a entidades do mundo real que existam ou que venham a existir.Representação da Realidade Comparação de Metodologias .Departamento Informática da UBI Engenharia de Software .Departamento Informática da UBI A gestão da empresa ou do projeto tem de “comprar” a mudança para a filosofia orientada por objetos. ou vice-versa. Por exemplo. Embora a abordagem orientada por objetos possa já ser considerada estabelecida e madura. na definição dos processos/funções que acedem e manipulam contas bancárias. em resposta às expectativas e requisitos dos utilizadores. o que é simples na abordagem orientada por objetos (ver figura). redução dos custos de manutenção do software. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 107 Cap. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 105 Cap.Cap.2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 108 Comparação de Metodologias . implica alguns cuidados na sua aplicação.Outros Aspetos Comparação de Metodologias . este fato permite reduzir as interdependências e facilitar a manutenção posterior.Departamento Informática da UBI Cap. Engenharia de Software . no desenho da base de dados que suporta contas bancárias) ou.Departamento Informática da UBI . A migração para a orientação por objetos tem de ser devidamente planeada para garantir a sua eficácia.Outros Aspetos As abordagens orientadas por objetos apresentam outras vantagens comparativamente com as abordagens estruturadas.2011/2012 Carlos Barrico . em particular tem de definir os objetivos comerciais para a mudança.2011/2012 Carlos Barrico . 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 106 Comparação de Metodologias . Não é trivial na abordagem estruturada introduzir-se posteriormente a noção de contas bancárias especializadas. Facilita a transferência de conhecimento através da adoção de “padrões de desenho”. Engenharia de Software . Providencia um framework (aplicacional ou de middleware) para facilitar a extensão do sistema. o foco é na definição do modelo de dados da conta bancária (isto é. pelo facto de levantar algumas questões: Exige uma nova forma de ”pensar“ o processo de desenvolvimento.

se a linguagem de programação utilizada pela organização for Cobol. Engenharia de Software .Cap. Por exemplo. RPG ou C e o ambiente de desenvolvimento for estruturado. 3 – Evolução das Metodologias de Desenvolvimentos de Software [Parte 1] 109 Comparação de Metodologias . então fará mais sentido aplicar metodologias estruturadas ao longo de todas as fases do projeto. não se deve concluir que esta é “sempre” mais adequada que a aproximação estruturada.Departamento Informática da UBI .Outros Aspetos Apesar das vantagens sublinhadas da abordagem da orientação por objetos no desenvolvimento de software. Há várias situações em que é mais correto seguir uma metodologia estruturada.2011/2012 Carlos Barrico .

Sign up to vote on this title
UsefulNot useful