Você está na página 1de 53

ENGENHARIA DE SOFTWARE Introduo

As trs primeiras dcadas da era do computador, foram marcadas pelo desenvolvimento de um hardware que reduzisse o custo de processamento e armazenagem de dados. Hoje o problema melhorar a qualidade e reduzir os custos dos softwares. O papel evolutivo do software:

Os primeiros anos (1950-meados 1960): orientao batch, distribuio limitada, software customizado Segunda era(meados de 1960-final de 1970): multiprogramao e sistemas multiusurios, tcnicas interativas, sistemas em tempo real, primeira gerao de SGBDs. Problema: manuteno do software (esforo despendido passou a tomar propores alarmantes) Terceira era(meados de 1970 at hoje): sistemas distribudos, inteligncia embutida, hdw de baixo custo, impacto de consumo,aumento da complexidade dos sistemas. Quarta era(comeando na atualidade): tecnologias orientadas a 1 objeto,sistemas especialistas, inteligncia artificial, redes neurais

ENGENHARIA DE SOFTWARE

Por que adotar prticas da Engenharia de Software ?


Evitar a demora na concluso dos softwares Reduzir os custos Pesquisa de erros antes de entregar o produto Medir o progresso enquanto o software est sendo desenvolvido

Observao: o custo do software ficou muito mais caro do que o do hardware.

ENGENHARIA DE SOFTWARE

Caractersticas do software

O software um elemento do sistema lgico e no fsico, portanto tem caractersticas que so consideravelmente diferentes das do hardware:

O software desenvolvido ou projetado por engenharia, no manufaturado no sentido clssico; Software no se desgasta(se deteriora). Comparao de curvas de falhas de hardware e software:

Obs.: a curva real mostra que ao serem introduzidas mudanas no software, provvel que novos erros aconteam (picos). Lentamente o nvel de falhas mnimo comea a se elevar- o software est se deteriorando devido s mudanas. Toda falha de software indica um erro no projeto ou no processo por meio do qual o projeto foi traduzido em cdigo 3 computacional. Portanto a manuteno do software mais complexa do que a do hardware.

ENGENHARIA DE SOFTWARE

Caractersticas do software (cont.)

A maioria dos softwares feita sob medida em vez de ser montado a partir de componentes existentes.

Componentes do Software

Os componentes de software so criados por meio de uma srie de converses que mapeiam as exigncias dos clientes para cdigo executvel. O projeto de software convertido numa forma de linguagem que especifica a estrutura de dados, os atributos procedimentais e os requisitos relacionados. A reusabilidade uma caracterstica importante de um componente de software de alta qualidade. O componente deve ser projetado e implementado de forma que possa ser reusado em muitos programas diferentes.

ENGENHARIA DE SOFTWARE Aplicaes do Software


O software pode ser aplicado a qualquer situao em que um conjunto especificado de passos procedimentais tiver sido definido. O contedo de informao e a determinncia so fatores importantes na natureza de um aplicativo Contedo: refere-se ao significado e forma dos dados que entram e das informaes geradas Determinncia de informao: refere-se previsibilidade da ordem e da oportunidade da informao. Um programa de engenharia aceita dados que tm uma ordem predefinida, executa os algoritmos sem interrupes e produz informaes em relatrios ou em formato grfico (so aplicaes determinadas). Um sistema operacional multiusurio, aceita entradas que tm contedo variado e regulagem de tempo arbitrria,executa algoritmos que podem ser interrompidos por condies externas e produz sada que varia como uma funo do ambiente e do tempo(so aplicaes indeterminadas).

ENGENHARIA DE SOFTWARE Aplicaes do software (cont.)


reas de software que indicam a amplitude das aplicaes potenciais: Software bsico: caracterizado por forte interao com o hardware, intenso uso por mltiplos usurios, operaes concorrentes que exigem escalonamento, compartilhamento de recursos e sofisticada administrao do processo, estruturas de dados complexas e mltiplas interfaces externas; Software de tempo real: software que monitora/analisa/controla eventos do mundo real. Tempo real diferente de interativo ou timesharing. Um sistema de tempo real deve responder dentro de restries estritas de tempo; o tempo de resposta de um sistema interativo pode ser normalmente ultrapassado sem causar resultados desastrosos. Software comercial: o processamento de informaes comerciais a maior rea particular de aplicao de software. Distintos sistemas evoluram para o software de sistemas de informaes administrativas. Tambm abrangem a computao interativa(processamento de transaes em pontos de vendas).
6

ENGENHARIA DE SOFTWARE Aplicaes do software (cont.)


reas de software que indicam a amplitude das aplicaes potenciais: Software cientfico e de engenharia: softwares caracterizados por algoritmos de processamento de nmeros. Novas aplicaes dentro da rea cientfica/engenharia esto se afastando dos algoritmos numricos convencionais (simulao de sistemas, cad e outras aplicaes interativas assumem caractersticas de tempo real e at mesmo de sistema bsico) Software embutido: reside em uma memria read-only e usado para controlar produtos e sistemas para os mercados industriais e de consumo. Software de computador pessoal: representa os mais inovadores projetos de interface com seres humanos. Software de Inteligncia Artificial: faz uso de algoritmos no numricos para resolver problemas complexos que no sejam favorveis computao ou anlise direta. Nos ltimos anos tem se desenvolvido um novo ramo da IA, chamado de redes neurais
7

ENGENHARIA DE SOFTWARE

Problemas

Pouca dedicao para coleta de dados sobre o processo de desenvolvimento de sofware. Insatisfao do cliente com o sistema concludo ocorre muito frequentemente. A comunicao entre o cliente e o desenvolvedor muito fraca. A qualidade do software frequentemente supeita. Os conceitos quantitativos slidos de confiabilidade e garantia de qualidade dos softwares so recentes. A manuteno pode ser difcil. A tarefa de manuteno a mais cara e a capacidade de manuteno no foi enfatizada como um critrio importante para a aceitao do software.

ENGENHARIA DE SOFTWARE

Mitos do Software

Mitos administrativos

Mito: J temos um manual completo para a construo do software. Realidade: Ser que ele consultado ? Reflete a moderna prtica de desenvolvimento de software ? completo ? Mito: J temos ferramentas de ltima gerao para desenvolvimento; foram comprados novos computadores.

Realidade: preciso mais do que um bom computador para desenvolver um software de alta qualidade. As ferramentas CASE (Computer-Aided Software Engineering) so mais importantes que o hardware para se conseguir boa qualidade e produtividade. Mito: Se estamos atrasados nos prazos podemos adicionar mais programadores e tirar o atraso.

Realidade: ...acrescentar pessoas em um projeto de software atrasado,torna-o ainda mais atrasado. Pessoas podem ser acrescentadas, mas de forma planejada e bem coordenada. 9

ENGENHARIA DE SOFTWARE

Mitos do Software

Mitos do Cliente

Mito: basta uma declarao geral dos objetivos para comear a escrever programas-detalhes ficam para mais tarde Realidade: Uma definio inicial ruim a principal causa de fracasso no desenvolvimento de software. Uma descrio formal de todos os aspectos fundamental. Mito: os requisitos de projeto modificam-se continuamente, mas as mudanas podem ser facilmente acomodadas, porque o software flexvel.

Realidade: os requisito de software se modificam mas o impacto da mudana varia de acordo com o tempo em que ela introduzida.

10

ENGENHARIA DE SOFTWARE

Mitos do Software

Mitos do Profissional

Mito: Assim que o software estiver pronto, nosso trabalho estar completo Realidade: os dados da indstria indicam que entre 50 e 70% de todo esforo gasto em um programa sero despendidos depois que ele for entregue. Mito: Enquanto o programa no estiver funcionando, no existe maneira de avaliar sua qualidade.

Realidade: um dos mecanismos mais efetivos de garantia da qualidade pode ser aplicada desde o comeo de um projeto- a reviso tcnica formal. Mito: A nica coisa a ser entregue em um projeto bem sucedido o programa funcionando.

Realidade: um programa funcionando s uma parte de uma configurao de software que inclui os elementos na figura seguinte. A documentao forma os alicerces para um desenvolvimento bem sucedido e fornece um guia para a tarefa de manuteno 11

ENGENHARIA DE SOFTWARE

Mitos do software

Mitos do Profissional

12

ENGENHARIA DE SOFTWARE

Definio de Engenharia de Software

O estabelecimento e uso de slidos princpios de engenharia para que se possa obter economicamente um software que seja confivel e que funcione eficientemente em mquinas reais. (Fritz Bauer) A Engenharia de Software abrange trs elementos fundamentais: mtodos, ferramentas e procedimentos.

13

ENGENHARIA DE SOFTWARE

Mtodos de Engenharia de Software: Proporcionam os detalhes de como fazer para construir o software. Envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto, anlise de requisitos de software e de sistemas, projeto de estrutura de dados, arquitetura de programa e algoritmo de processamento, codificao, teste e manuteno. Ferramentas de engenharia de Software: proporcionam apoio automatizado ou semi-automatizado aos mtodos. Quando as ferramentas so integradas de forma que a informao criada por uma ferramenta possa ser usada por outra, estabelecido um sistema de suporte ao desenvolvimento de software chamado engenharia de software auxiliado por computador- CASE. O CASE combina software, hardware e um banco de dados de engenharia de software. Procedimentos da engenharia de software: constituem o elo de ligao que mantm juntos os mtodos e as ferramentas e possibilita o desenvolvimento racional e oportuno de software de computador. Os procedimentos definem a sequncia em que os mtodos sero aplicados, os produtos que se exige que sejam entregues (documentos relatrios e formulrios), os controles que ajudam a assegurar a qualidade e a coordenar as mudanas e os marcos de referncia que possibilitam aos gerentes avaliar o progresso.
14

ENGENHARIA DE SOFTWARE

Ciclo de vida clssico

15

ENGENHARIA DE SOFTWARE

Ciclo de vida clssico

Anlise e engenharia de sistemas: inicia-se com o estabelecimento dos requisitos para todos os elementos do sistema e prossegue com a atribuio de certo subconjunto desses requisitos ao software. Essa viso essencial quando o software deve fazer interface com outros elementos (pessoas, hardware e banco de dados). A anlise e engenharia de sistemas envolve a coleta dos requisitos em nvel de sistema, com uma pequena quantidade de projeto e anlise de alto nvel

16

ENGENHARIA DE SOFTWARE Ciclo de vida clssico (cont.)

Anlise de requisitos de software: o processo de coleta de requisitos intensificado e concentrado especificamente no software. Para entender a natureza dos programas a serem construdos, o engenheiro (analista) de software deve compreender o domnio da informao para o software descrito, bem como a funo, desempenho e interface exigidos. Os requisitos, tanto para o sistema como para o software, so documentados e revistos com o cliente.

17

ENGENHARIA DE SOFTWARE

Ciclo de vida clssico (cont.)

Projeto: o projeto do software , de fato, um processo de mltiplos passos e se concentra em quatro atributos distintos do programa: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterizao de interface. O processo de feitura do projeto traduz as exigncias numa representao do software que pode ser avaliada quanto qualidade antes que a codificao se inicie. Como os requisitos, o projeto documentado e torna-se parte da configurao do software.

18

ENGENHARIA DE SOFTWARE

Ciclo de vida clssico (cont)

Codificao: o projeto deve ser traduzido numa forma legvel por mquina. Se o projeto for executado detalhadamente, a codificao pode ser executada mecanicamente. Teste: assim que o cdigo for gerado, inicia-se a realizao de testes. O processo de realizao de testes concentra-se nos aspectos lgicos internos do software,garantindo que todas as instrues tenham sido testadas e concentra-se tambm nos aspectos funcionais externos, ou seja, realizando testes para descobrir erros e garantir que a entrada definida produza resultados reais que concordem com os resultados exigidos.
19

ENGENHARIA DE SOFTWARE Ciclo de vida clssico (cont.)

Manuteno: indubitavelmente o software sofrer mudanas depois que for entregue ao cliente (uma possvel excesso o software embutido). Ocorrero mudanas porque erros foram encontrados, porque o software deve ser adaptado a fim de acomodar as mudanas em seu ambiente externo ou porque o cliente exige acrscimos funcionais ou de desempenho. A manuteno de software reaplica cada uma das etapas precedentes do ciclo de vida a um programa existente e no a um novo.

20

ENGENHARIA DE SOFTWARE

Prototipao

Processo que capacita o desenvolvedor a criar um modelo do software que ser implementado. O modelo pode assumir uma das trs formas: (1) um prottipo em papel ou modelo baseado em PC que relata a interao homem-mquina de uma forma que capacita o usurio a entender quanta interao ocorrer; (2) um prottipo de trabalho que implementa algum subconjunto da funo exigida do software desejado; (3) um programa existente que executa parte ou toda a funo desejada, mas que tem outras caractersticas que sero melhoradas em um novo esforo de desenvolvimento.
21

ENGENHARIA DE SOFTWARE

Prototipao:

Idealmente o prottipo serve como mecanismo para identificar os requisitos de software. Ainda que possam ocorrer problemas, a prototipao um paradigma eficiente a engenharia de software. Ele ser destrudo e o software real ser projetado.

22

ENGENHARIA DE SOFTWARE
O Modelo Espiral
Este modelo foi desenvolvido para abranger as melhores caractersticas tanto do ciclo de vida clssico como da prototipao, acrescentando um novo elemento: a anlise de riscos. O modelo define quatro importantes atividades: 1- Planejamento: determinao dos objetivos, alternativas e restries 2- Anlise dos riscos: anlise das alternativas e identificao/resoluo dos riscos 3- Engenharia: desenvolvimento do produto no nvel seguinte 4- Avaliao feita pelo cliente: avaliao dos resultados da engenharia

23

ENGENHARIA DE SOFTWARE
Tcnicas de quarta gerao
Abrange um amplo conjunto de ferramentas de software que tm uma coisa em comum: cada uma delas possibilita que o desenvolvedor especifique algumas caractersticas num nvel elevado. A ferramenta gera automicamente, o cdigofonte, tendo como base a especificao do desenvolvedor. O ambiente de desenvolvimento de software que sustenta o paradigma 4GT inclui algumas ou todas as ferramentas: linguagens no-procedimentais (descrevem o que fazer, mas no como fazer- SQL) para consulta a banco de dados, gerao de relatrios, manipulao de dados, interao e definio de telas, gerao de cdigos, capacidade grfica de alto-nvel e capacidade de planilhas eletrnicas. O paradigma representado na figura abaixo:
Coleta de requisitos Estratgia de projeto Implementa o com 4GL Teste

24

ENGENHARIA DE SOFTWARE
Tcnicas de quarta gerao (cont.)
Para pequenas aplicaes, possvel passar diretamente da etapa de coleta de dados para a implementao usando 4GL A implementao usando 4GL possibilita que o desenvolvedor represente os resultados desejados de forma que resulte em gerao automtica de cdigo. Para transformar a implementao de uma 4GT num produto, o desenvolvedor deve realizar testes cuidadosos, desenvolver uma documentao significativa e executar todas as atividades de transio exigidas nos outros paradigmas O software desenvolvido por 4GT deve ser construdo de modo que possibilite rpida manuteno. As tcnicas 4GT devero preencher a lacuna deixada pelos paradigmas convencionais, na demanda cada vez maior de novos softwares.

25

ENGENHARIA DE SOFTWARE
Combinando paradigmas
Em muitos casos os paradigmas podem e devem ser combinados de forma que as potencialidades de cada um possam ser obtidas em um nico projeto.

26

ENGENHARIA DE SOFTWARE
Viso Genrica da Engenharia de Software
O processo de desenvolvimento de software contm trs fases genricas:
Definio: focaliza o qu; identificao de quais informaes precisam ser processadas, qual a funo e desempenho desejados, interfaces, restries do projeto e quais critrios de validao so exigidos. Independente do paradigma utilizado, trs etapas ocorrero:
Anlise do sistema: define o papel de cada elemento em um sistema baseado em computador, atribuindo, em ltima anlise, o papel que o software desempenhar; Planejamento do projeto do software: assim que o escopo estabelecido, os riscos so analisados, os recursos alocados, os custos estimados e as tarefas e a programao de trabalho definidas; Anlise de requisitos: o escopo definido para o software proporciona uma direo, mas uma uma definio detalhada do domnio da informao e da funo do software necessria antes que o trabalho se inicie.

27

ENGENHARIA DE SOFTWARE
Viso Genrica da Engenharia de Software (cont.)
Desenvolvimento: focaliza o como. Durante a definio, o desenvolvedor define como a estrutura de dados e a arquitetura de software tm que ser projetadas, como os detalhes procedimentais tm que ser implementados, como o projeto ser traduzido numa linguagem de programao (ou no-procedimental) e como os testes tm que ser realizados. Trs passos ocorrero:
Projeto de software: traduz os requisitos do software num conjunto de representaes que descrevem a estrutura de dados, a arquitetura, o procedimento algortimico e as caractersticas da interface. Codificao: as representaes do projeto devem ser convertidas numa linguagem artificial que resulte em instrues que possam ser executadas. A etapa da codificao realiza esta converso. Realizao de testes: logo que implementado, o software deve ser testado para que se possa descobrir defeitos de funo, lgica e implementao.

28

ENGENHARIA DE SOFTWARE
Viso Genrica da Engenharia de Software (cont.)
Manuteno: concentra-se nas mudanas que esto associadas correo de erros, adaptaes exigidas medida que o ambiente do software evolui e ampliaes produzidas por exigncia do cliente. Trs tipos de mudanas so encontradas durante a fase de manuteno:
Correo: a manuteno corretiva muda o software para corrigir defeitos. Adaptao: com o passar do tempo, o ambiente original (p.ex. CPU, sistema operacional e perifricos) para o qual o software foi desenvolvido provavelmente mudar. A manuteno adaptativa resulta em modificaes no software a fim de acomodar as mudanas em seu ambiente. Melhoramento funcional: medida que o software usado o cliente reconhecer funes adicionais que oferecero benefcios. A manuteno perfectiva estende o software para alm das exigncias funcionais originais.

29

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares
Anlise Essencial de Sistemas
Requerimento verdadeiro: requerimento verdadeiro uma caracterstica ou capacidade que o sistema deve ter para cumprir sua finalidade, independentemente de como o sistema implementado. A especificao do sistema deve conter todos os requerimentos verdadeiros e somente eles. Requerimento falso: requerimento falso se o sistema for capaz de cumprir sua finalidade sem a implementao deste requerimento. A Anlise Essencial de Sistemas uma abordagem para especificar Sistemas de Informao atravs da identificao e modelagem dos requerimentos verdadeiros do sistema, componentes do fluxo e informaes necessrias ao negcio da instituio Essncia do Sistema: o conjunto de requerimentos verdadeiros de um sistema. Indica o que o sistema vai fazer sem mencionar como ele ser implementado. A essncia de um sistema composta das atividades essenciais e memria essencial.
30

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
Anlise Essencial de Sistemas (cont.)
Sistemas de respostas planejadas: so sistemas que apresentam uma resposta a eventos pr-definidos, que podem ocorrer temporalmente ou iniciados por entidade externa localizada em seu ambiente.
Evento: uma mudana no ambiente do sistema qual ele reage. Resposta: o conjunto de aes realizados pelo sistema em reao a um evento.

Classificao dos Eventos:


Eventos externos: iniciados por entidades no ambiente. Ocorrem em intervalos de tempo imprevisveis (ex.:cliente solicita extrato, cliente solicita saque) Evento temporal: so iniciados pela passagem do tempo (ex.: hora de emitir contracheque, hora de listar clientes em atraso)

31

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
Anlise Essencial de Sistemas (cont.)
Atividades essenciais: todas as tarefas que o sistema teria de fazer mesmo se implementado com a tecnologia perfeita. So divididas em atividades fundamentais, atividades custodiais e atividades essenciais compostas.
Atividades fundamentais: atividade que executa uma tarefa que parte da finalidade do sistema Atividades custodiais: estabelece e mantem a memria essencial do sistema, armazenando as informaes necessrias s atividades fundamentais. Atividades essenciais compostas: so atividades que executam funes que fazem parte da finalidade do sistema e atualizam a memria essencial.

Memria essencial: conjunto de todos os dados dos quais o sistema um sistema tecnologicamente perfeito tem que se lembrar.

32

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
Anlise estruturada
Conceito fundamental:. Visa a construo de um modelo com fluxo e contedo das informaes divididas em parties funcionais, descrevendo a essncia daquilo que deve ser construdo. A ferramenta utilizada o DFD (Diagrama de Fluxo de Dados). Benefcios :
Benefcios: os usurios obtm uma idia mais clara do sistema proposto pelo diagrama de fluxo de dados, do que a obtida atravs da narrativa; A apresentao em termos de fluxo lgico consegue mostrar os malentendidos e pontos controversos; O uso do dicionrio de dados economiza tempo ao resolver rapidamente os casos em que as pessoas chamam as mesmas coisas por diferentes nomes

Problemas:
O esforo, a formalidade e o grau de detalhe necessrios,especialmente na construo do dicionrio de dados, muitas vezes sofrem resistncia; Necessria uma orientao dos usurios e treinamento dos analistas.

33

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
Anlise estruturada(cont.)
Diagrama de fluxo de dados: uma representao em rede dos processos (funes e procedimentos) de um sistema e dos dados que ligam estes processos. Mostra o que um sistema faz mas no como faz. a principal ferramenta de modelagem da anlise estruturada e usada para dividir o sistema em uma hierarquia de processos. Neste diagrama constam:
Fluxo de informaes: representam um sistema de canaliza por onde as informaes fluem. So representadas por flechas direcionadas no sentido do fluxo; Processos: so as atividades realizadas no sistema. So representados por um crculo ou por um retngulo de bordas arredondadas. Depsitos de dados: so representados por duas linhas paralelas, com o nome do depsito entre as linhas. Entidade externa: representada por um retngulo. Obs: possvel representar, tambm, sistemas em tempo real.

34

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
Anlise estruturada(cont.) Exemplo de DFD:

aluno

Solicita notas

Gerar relatorios notas individuais

notas

aluno

notas

Secretaria

Informa notas

Processar notas

35

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
Anlise Orientada a Objetos.
A AOO baseia-se em conceitos simples que o homem adquire desde a infncia, como objetos e atributos, classes e membros, todo e partes do todo Enfoque tradicional: compreenso do sistema commo um conjunto de programas que executam processos sobre os dados Enfoque AOO: o sistema uma coletnea de objetos que intereragem entre si,com caractersticas prprias, representadas por atributos(dados) e operaes(processos). Os mtodos de OO apresentam uma viso mais integrada das funes e dados O sistema OO estruturado atravs de objetos que contemplam funes + dados Resultados
Produtos mais estavis e de melhor qualidade Processo de desenvolvimento que permite: Melhor entendimento do sistema e seu ambiente Melhor entendimento do domnio de aplicao Maior independncia da implementao at estgios mais avanados

36

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
Anlise Orientada a Objetos.
Quando usar Anlise OO
Projeto de grande porte (confinamento de informao) Requisitos no completamente fechados (modelos relativamente estveis) Requisitos vagos, incompletos ou inconsistentes (recurso para identificar as informaes) Novas aplicaes (abordagem sistemtica para melhor entendimento) Equipe com especialidades diversas (linguagem comum) Sistemas crticos (definio mais sistemtica da lgica)

Manuteno de sistemas OO
Quando bem modelado, estruturado atravs de objetos do domnio do problema O sistema pode ser mantido o mais prximo possvel de uma viso conceitual do mundo real H mais transparncia na passagem da fase de modelagem para a fase de construo, no exigindo reorganizao do modelo. Obs: uma boa modelagem do sistema atravs de objetos exige um bom conhecimentodo domnio do problema.

37

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
Anlise Orientada a Objetos (cont.)
O projeto, a Anlise e a Programao so atividades distintas
A Anlise OO se preocupa com a modelagem dos objetos para o domnio da aplicao O Projeto OO se preocupa com o desenvolvimento de um modelo de sistema que implemento os requisitos definidos pela AOO A Programao OO se preocupa com aimplementao do Projeto OO usando uma linguagem de programao OO (como C++ ou Java)

38

ENGENHARIA DE SOFTWARE
Anlise OO
UML (UNIFIED MODELING LANGUAGE): uma linguagem para especificao, visualizao,construo e documentao de artefatos de sistemas de software. Diagramas da UML 2.0
Use Case Atividade Classe Objetos Interaes entre o sistema e usurios ou outro sistema externo. Muito til no mapeamento de requisitos para o sistema Atividades sequenciais e paralelas dentro do sistem Tipos de classes, interfaces e o relacionamento entre elas Instncia de objetos de classe definidas no diagrama de classes.

Sequncia

Interaes entre objetos onde a ordem de interaes importante.

Comunicao

As maneiras pelas quais os objetos interagem e as conexes que so necessrias para suportar as interaes. 39

ENGENHARIA DE SOFTWARE
Anlise OO
Diagramas da UML 2.0(cont.)
Timing Vista geral de Interaes Composite Structure Componente Pacotes Estado Implantao Interaes entre objetos onde o tempo importante Usado para reunir os diagramas de sequncia, comunicao e timing juntos para capturar uma interao importante que ocorre dentro do sistema. A parte interna das classes ou componentes. Pode descrever relacionamentos entre as classes dentro de um determinado contexto Componentes importantes dentro do sistema e as interfaces usadas para interao entre eles A organizao hierrquica de grupos de classes e componentes O estado de um objeto atravs seu tempo de vida e os eventos que podem trocar aquele estado Com o sistema ser finalmente implantado em uma situao do mundo real

40

ENGENHARIA DE SOFTWARE
Anlise OO
Use Cases: um use case um case (ou situao) onde o seu sistema usado para preencher um ou mais dos requisitos dos usurios; um use case captura uma parte da funcionalidade que o sistema prov. Use Case o corao do modelo, desde que afeta e guia todos os outros elementos dentro do projeto do sistema. Especifica somente o que o sistema prope a fazer, isto os requisitos funcionais. Ele no especifica o que o sistema no deve fazer, isto , os requisitos no funcionais (p.ex. objetivos de performance e linguagens de programao, etc.).
Viso Lgica

Viso de Processos

Viso Use Case Viso fsica Viso de desenvol vimento

Use Case um excelente ponto de partida para qualquer situao no desenvolvimento, teste e documentao de um sistema OO. 41

ENGENHARIA DE SOFTWARE
Anlise OO
Use Case:
Actor: so os elementos externos que interagem com o sistema. Devem ser nomeados de forma que tanto o projetista e o usurio no tenham dvidas de quem seja. Caso especial quando o sistema precisa executar alguma ao baseado no clock interno. Apesar de ser algo interno, ele pode ser considerado um ator.
Representao do ator:

42

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
O Desenvolvimento gil
Em 2001, Kent Beck e outros 16 desenvolvedores, produtores e consultores de software assinaram o Manifesto para o Desenvolvimento gil de Software. Eles declararam:
Indivduos e interaes em vez de processos e ferramentas; Softwares funcionando em vez de documento abrangente; Resposta a modificaes em vez de seguir um plano. Isto , ainda que h valor nos itens direita, valorizamos mais os itens esquerda.

43

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
O Desenvolvimento gil (cont.)
O que ?: combina uma filosofia e um conjunto de diretrizes de desenvolvimento. A filosofia encoraja a satisfao do cliente e a entrega incremental do software logo de inci; as equipes de projeto pequenas, altamente motivadas; mtodos informais; produtos de trabalho de engenharia de software mnimos e simplicidade global do desenvolvimento. As diretrizes de desenvolvimento enfatizam a entrega em contraposio anlise e ao projeto e a comunicao ativa e contnua entre cliente e desenvolvedores. Quem faz ?: engenheiros de software e outros interessados no prjeto (gerente, cliente e usurios finais) trabalham juntos em uma equipe giluma equipe que auto-organizada e controla seu prprio destino. Por que importante ?: o ambiente moderno de negcios que cria sistemas baseados em computador e produtos de software apressado e sempre mutvel. A engenharia gil de software representa uma alternativa razovel para a engenharia de software convencional para certas categorias e tipos de software. Tem sido demonstrado que ela entrega rapidamente sistemas bem sucedidos.

44

ENGENHARIA DE SOFTWARE
Paradigmas de desenvolvimento de softwares (cont.)
O Desenvolvimento gil (cont.)
Quais so os passos ?: o desenvolvimento gil poderia ser melhor denominado pequena engenharia de software. As atividades bsicas de arcabouo-comunicao com o cliente, o planejamento, a modelagem, construo, entrega e avaliao- permanecem. Mas elas so reduzidas a um conjunto mnimo de tarefas que leva a equipe do projeto construo e entrega Qual o produto do trabalho ?: clientes e engenheiros de software que tm adotado a filosofia gil tm a mesma impresso- o nico produto de trabalho realmente importante um incremento de software operacional que entregue ao cliente na data comobinada. Como tenho a certeza de que fiz corretamente ?: se a equipe gil concordar que o processo funciona e produzir incrementos de software em condies de serem entregues e que satisfaam o cliente, tudo foi feito corretamente. Obs: um erro considerar que a agilidade lhe d licena de improvisar solues. Um processo necessrio e disciplina essencial.
45

ENGENHARIA DE SOFTWARE

Paradigmas de desenvolvimento de softwares (cont.)


O Desenvolvimento gil (cont.)
A Aliana gil define 12 princpios:
1. A maior prioridade satisfazer o cliente desde o incio por meio de entrega contnua de software 2. Modificaes de requisitos so bem-vindas, mesmo que tardias no desenvolvimento; 3. Entregas de softwares funcionando frequentemente, a cada duas duas semanas at dois meses, de preferncia no menor espao de tempo; 4. O pessoal de negcio e os desenvolvedores devem trabalhar juntos diariamente durante todo o projeto; 5. Construo de projetos em torno de indivduos motivados. Fornecer o ambinente e apoio e confiar neles; 6. O mtodo mais eficiente e efetivo de levar informao para e dentro de uma equipe de desenvolvimento a conversa face a face; 7. Software funcionando a principal medida de progresso; 8. Processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios, devem ser capazes de manter um ritmo constante, indefinidamente; 9. Ateno contnua excelncia tcnica e ao bom projeto facilitam a agilidade 10. Simplicidade essencial 11. As melhores arquiteturas, requisitos e projetos surgem de equipes autoorganizadas 12. Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva, ento sintoniza e ajusta adequadamente seu comportamento.

46

ENGENHARIA DE SOFTWARE

Paradigmas de desenvolvimento de softwares (cont.)


O Desenvolvimento gil (cont.)
O que um processo gil ? : qualquer processo gil de software caracterizado de modo que atenda a trs suposies-chave sobre a maioria dos projetos de software:
1. difcil prever antecipadamente quais os requsitos de software vo persistir e quais sero modificados. igualmente difcil prever como as prioridades do cliente sero modificadas medida que projeto prossegue; 2. Para muitos tipos de software, o projeto e a construo so intercalados, isto , as duas atividades devem ser realizadas juntas de modo que os modelos de projeto sejam comprovados a medida que so criados. difcil prever o quanto de projeto necessrio antes que a construo seja usada para comprovar o projeto; 3. Anlise, projeto, construoe testes no so to previsveis (do ponto de vista do planejamento) como gostaramos. Dessas trs suposies, surge uma questo: como criar um processo que possa gerenciar a imprevisibilidade ? A resposta est na adaptabilidade do processo (as modificaes rpidas do projeto e das condies tcnicas). Um processo gil deve ser adaptvel. 47

ENGENHARIA DE SOFTWARE

Mtricas de software
Mtricas de software referem-se a uma ampla variedade de medidas de software de computador. Dentro do contexto de gerenciamento de software a preocupao primeiramente com mtricas de produtividade e de qualidade. Para propsitos de planejamento e estimativa,o interesse histrico. Qual a produtividade no desenvolvimento do software de projetos passados ? Qual a qualidade do software que era produzido ? Com isto pode ajudar a planejar e estimar com maior preciso ? Medidas do Software: dificuldades so o que medir e dificuldades para avaliar as medidas que so obtidas.
Razes para medio do software:
1. 2. 3. Indicar a qualidade do produto; Avaliar a produtividade das pessoas que fazem o produto; Avaliar os benefcios (em termos de produtividade e qualidade) derivados de novos mtodos e ferramentas; 4. Formar uma linha bsica para estimativas; 5. Ajudar a justificar os pedidos de novas ferramentas ou treinamento adicional. As medidas do mundo fsico podem ser divididas em duas categorias: medidas diretas (tamanho do parafuso) e medidas indiretas (a qualidade do parafuso). As mtricas de software podem ser divididas em categorias de maneira idntica.

48

ENGENHARIA DE SOFTWARE
Mtricas de software (cont.)
Entre as medidas diretas do processo de engenharia de software incluem-se o custo e o esforo aplicados. As medidas diretas do produto incluem:
As linhas de cdigos produzidas A velocidade de execuo Tamanho da memria Defeitos registrados ao longo de certo espao de tempo Funcionalidade Qualidade Complexidade Eficincia Confiabilidade Manutenibilidade

Medidas indiretas:

49

ENGENHARIA DE SOFTWARE
Mtricas de software (cont.)
Diviso das mtricas em categorias:
Mtricas de produtividade: concentram-se na sada do processo de engenharia de software; Mtricas da qualidade: oferecem uma indicao de quo estreitamente o software conforma-se s exigncias implcitas e explctas do cliente; Mtricas tcnicas: concentram-se na caracterstica do software(p.ex. complexidade lgica, grau de modularidade); Mtricas orientadas ao tamanho: usadas para compilar as medies diretas da sada e da qualidade da engenharia de software; Mtricas orientadas para a funo: oferecem medidas indiretas; Mtricas orientadas s pessoas: compilam as informaes sobre a maneira segundo a qual as pessoas desenvolvem software de computador e percepes humanas sobre a efetividade das ferramentas e mtodos.

50

ENGENHARIA DE SOFTWARE
Mtricas de software (cont.)
Mtricas orientadas ao tamanho: so medidas diretas do software e do processo pelo qual ele desenvolvido.
Tabela de dados orientado ao tamanho: Projeto Esforo $ KLOC Pags. Doc. erros pessoas

aaa-1 ccc-2 fff-03

24 62 43

168 440 314

12.1 27.2 20.2

365 1224 1050

29 86 64

3 5 6

Obs: 1- esforo medido em pessoas-ms 2- KLOC: milhares de linhas de cdigo 3- erros: quantidade de erros aps 1 ano de entrega ao cliente
51

ENGENHARIA DE SOFTWARE
Mtricas de software (cont.)
Mtricas orientadas ao tamanho:
Mdias computadas a partir da tabela:
Produtividade= KLOC/pessoa_ms Qualidade=defeitos/KLOC Custo=$/LOC Documentao=pginas de documentao/KLOC A partir da pode-se depreender que: 1- para o projeto aaa-01: - produtividade = 12.1/24 = 0.5041 -qualidade = 29/12.1 = 2.39 2-para o projeto ccc-04: -produtividade = 27.2/62 = 0.43 -qualidade = 86 / 27.2 = 3.161

52

ENGENHARIA DE SOFTWARE
Referncias:
Engenharia de Software Roger S. Pressman 3 e 6 Edies- Makron Books www.alexandre.eletrica.ufu.br- Prof. Dr. Alexandre Cardoso www2.dem.inpe.br/ijar/analiseestruturada.doc www2.uniijui.tche.br/~evandro/ijui/pds/analise_estruturada.doc Desenvolvendoo Aplicaes com UML 2.0- Ana Cristina Melo Brasport- 2 edio. Learning UML 2.0 Kim Hamilton, Rusel Miles- OReilly- abril, 2006

53