Home

Engenharia de Software

1. M KLJ EEJ D D D Cluster 3 Cluster 1 Cluster 2 Figura 8 4 Integra o Bottom Up 54 Compara o entre as Duas estRat cias Quando se tenta confrontar as duas estrat gias descritas nas se es precedentes n o dif cil antecipar que a vantagem de um pode constituir se na desvantagem do outro No caso da abordagem top down a maior desvantagem sem d vida a necessidade de se construir stubs para representar m dulos subordinados que n o foram suficientemente testados por raz es bvias Por outro lado a possibilidade de se ter resultados sobre as principais de controle uma vez que s o os m dulos de mais alto n vel que suportam estas fun es constitui se num ponto a favor desta estrat gia aa AQ CAP 8 TESTE DE SOFTWARE PROF Vit rio BRUNO MAZZOLA J no caso da estrat gia bottom up pode se dizer que o programa completamente inexistente at que o ltimo m dulo seja finalmente integrado Mas esta defici ncia largamente compensada pelo fato de haver muito maior facilidade para projetar os casos de teste e pela n o exig ncia na cria o de stubs para a realiza o dos testes dos m dulos dos n veis mais altos 6 teste De VALIDA O O teste de valida o tem por objetivo determinar se o programa mesmo que funcionando corretamente em consequ ncia das etapas de
2. DEFINI O DESENVOLVIMENTO MANUTEN O Figura 1 1 Influ ncia das altera es de requisitos no custo de um sistema 2 2 2 Mitos do Profissional Mito 6 Ap s a edi o do programa e a sua coloca o em funcionamento o trabalho est terminado Realidade 6 O que ocorre na realidade completamente diferente disto Segundo dados obtidos a partir de experi ncias anteriores 50 a 70 do esfor o de desenvolvimento de um software despendido ap s a sua entrega ao cliente manuten o Mito 7 Enquanto o programa n o entrar em funcionamento imposs vel avaliar a sua qualidade Realidade 7 Na realidade a preocupa o com a garantia do software deve fazer parte de todas as etapas do desenvolvimento sendo que ao fim de cada uma destas etapas os documentos de projeto devem ser revisados observando crit rios de qualidade Mito 8 O produto a ser entregue no final do projeto o programa funcionando Realidade 8 O programa em funcionamento uma das componentes do software al m do software um bom projeto deve ser caracterizado pela produ o de um conjunto importante de documentos os quais podem ser identificados com aux lio da figura 1 2 3 PARADIGMAS DA ENGENHARIA DE SOFTWARE 3 1 Derm o De Encenxaria De Sortware Os problemas apontados nas se es anteriores n o ser o claro resolvidos da noite para o dia mas reconhecer a exist ncia dos problemas e defin
3. Casos de Teste Stub Stub Resultados Figura 8 2 Ambiente de teste de unidade Uma abordagem muitas vezes adotada a abordagem big bang um processo de integra o n o incremental na qual todos os m dulos s o associados e o programa testado como um todo Na maioria dos testes realizados segundo esta abordagem o resultado n o outro sen o catastr fico A corre o dos erros torna se uma tarefa extremamente complexa principalmente porque bastante dif cil isolar as causas dos erros dada a complexidade do programa completo Mesmo quando alguns erros s o detectados e corrigidos outros aparecem e o processo ca tico recome a A integra o incremental tem se mostrado mais eficiente neste contexto uma vez que segundo esta abordagem o programa vai sendo constru do aos poucos e testado por partes Neste tipo de integra o o isolamento das causas de erros e suas corre es s o obtidos mais facilmente Al m disso o teste das interfaces pode ser feito com maior efic cia 8 8 CAP 8 TESTE DE SOFTWARE PROF Vit rio BRUNO MAZZOLA As se es a seguir v o apresentar a descri o de duas estrat gias de teste de integra o bastante cl ssicas a integra o top down e a integra o bottom up 5 2 Imecra o tor Down A integra o top down ilustrada na figura 8 3 uma estrat gia de integra o incremental onde os m dulos s o integrado
4. Linha Arco Linha Livre Pol gono raio 7 E pontos n mero lados s extremidades ngulo origem em di metro controle v rtices nqulo arco mostrar mostrar mostrar mostrar mostrar mostrar rodar Figura 9 12 Heran a aplicada a figuras gr ficas La O monero pm mico O modelo din mico descreve os aspectos do sistema que dizem respeito ao tempo e sequ ncia de eventos opera es Este modelo tenta capturar o controle aspecto de um sistema que descreve as sequ ncias de opera o que ocorrem em resposta a est mulos externos sem levar em conta o que as opera es fazem quem as ativa e como s o implementadas Os conceitos utilizados nesta modelagem din mica s o os de eventos que representam os est mulos externos e de estados que representam os valores de objetos A representa o gr fica um diagrama de estados que representa os estados e a sequ ncia de eventos permitidos num sistema para uma classe de objetos Os estados e eventos podem ainda serem organizados de forma hier rquica e representados num diagrama de estados estruturado 4 2 1 Eventos e estados Um estado caracterizado pelos valores dos atributos e pelas liga es mantidas por um objeto Um evento corresponde a um estimulo individual de um objeto a um outro O diagrama de estados representa o modelo de eventos estados e transi es de estado para um a classe dada O modelo din mico consiste de v rios diagramas de estados u
5. gerado ao final da etapa de planejamento Uma ilustra o sintetizando os passos essenciais desta tarefa apresentada figura 4 2 3 DeFMI O De UM CRONOGRAMA A defini o de um cronograma pode ser obtida segundo duas diferentes abordagens dados da an lise dos riscos 1 p Risco 1 lt X a es de administra o dos riscos 1 RE a E dados da an lise dos riscos 2 Gerenciamento lt Risco 2 lt dos riscos gt a es de administra o dos riscos 2 A pi h dados da an lise dos riscos n Pa l i T Risco n lt p Plano de Administra o Ea e Monitora o dos Riscos a es de administra o dos riscos n Figura 4 2 S ntese da tarefa de Administra o e Monitora o dos Riscos a primeira baseada na defini o pr via de um prazo de entrega do software neste caso o planejamento deve ser feito de modo a distribuir os esfor os ao longo do prazo estabelecido a segunda est relacionada a uma discuss o de limites cronol gicos aproximados para cada etapa do desenvolvimento sendo que o prazo de entrega do software seja estabelecido a partir de t cnicas de planejamento da Engenharia de Software E cur CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF Vit rio BRUNO MAZZOLA evidente que a primeira abordagem a mais encontrada nos projetos de software Um cronograma bem definido pode trazer enormes benef cios a um projeto de software sendo s vezes
6. Ee ai a dr oligo o ets o RAND E RDOE NDA PURO E PRE RR EDER EO PRO APOS RR MPR E Se RR PERENE 74 Pa 04 Ns o 8 oz o rrene RP OR e PR RP RP R E 74 Caracter sticas das Linguagens de Programa o 7 2 Classes de LINgUADENS pa uatioua sonia aetr caderas ada asa pa parada a tada 7 5 Estilo d COMICA O Esposa erga a O ro ER ER gira ED E E 7 7 Codifica o e Efici ncia sssenennneeeeeeseerenerrnnttsstrttrrrnntresrrrnnrrnnnrssrrrnrn enn 7 8 CarituLo 8 teste De SOFtwARe AO Or E OOTA INtrod O hri er aE RR RR RR e RP RR 8 1 Fundamentos do Teste de Software seserrsessrrreeerrrreerrrresrnrrrerrrrresnrrreen 8 1 Modalidades de Teston ne rr ea rertasrr ea er terrena 8 2 Teste de Unidades saias ue ou a DES inatas des dE doada a TT densa 8 4 Teste de Integra o zsaisisaiagassaseaualcani tos Feieaiainadi ques Padeapalnadn toe Fuisnia lisos napebra 8 7 Teste de ValdA O cenas nrr aa eninodfauaGa cas eni ante 8 10 Teste de SIstem asma La adsl da a dead a raca 8 12 Car ruLo 9 An LISe e PROJeto ORIENTADOS A OBJeros O GN GIN a BiBLIOGRAFIa Anexo aji e jo E Tere o PRIDE RD TAN PR RR 9 1 Orienta o a objetos CONCENOS cosas apaagre nossos aque qoapai assar saaegape cp sta nana qua 9 1 Desenvolvimento Orientado a Objetos a 9 3 Modelagem Orientada a Objetos aaa 9 4 An lise Orientada a Objetos esse
7. Realidade 1 Isto verdadeiramente n o o suficiente preciso que a equipe aplique efetivamente os conhecimentos apresentados no manual necess rio que o que conste no dado manual reflita a moderna pr tica de desenvolvimento de software e que este seja exaustivo com rela o a todos os problemas de desenvolvimento que poder o aparecer no percurso Mito 2 A equipe tem ferramentas de desenvolvimento de software de ltima gera o uma vez que eles disp em de computadores de ltima gera o Realidade 2 Ter sua disposi o o ltimo modelo de computador seja ele um mainframe esta o de trabalho ou PC pode ser bastante confort vel para o desenvolvedor do software mas n o oferece nenhuma garantia quanto qualidade do software desenvolvido Mais importante do que ter um hardware de ltima gera o ter ferramentas para a automatiza o do desenvolvimento de software as ferramentas CASE Mito 3 Se o desenvolvimento do software estiver atrasado basta aumentar a equipe para honrar o prazo de desenvolvimento Realidade 3 Isto tamb m dificilmente vai ocorrer na realidade algu m disse um dia que acrescentar pessoas em um projeto atrasado vai torn lo ainda mais atrasado De fato a introdu o de novos profissionais numa equipe em fase de condu o de um projeto vai requerer uma etapa de treinamento dos novos elementos da equipe para isto ser o utilizados elementos que est o envolvido
8. o de encontrar erro contrariando a falsa id ia de que uma atividade de teste bem sucedida aquela em que nenhum erro foi encontrado A etapa de teste deve ser conduzida de modo que o maior n mero de erros poss vel seja encontrado com um menor disp ndio de tempo e esfor o 8 2 CAP 8 TESTE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 2 2 O PROJETO De casos De teste A realiza o com sucesso da etapa de teste de um software deve ter como ponto de partida uma atividade de projeto dos casos de teste deste software Projetar casos de teste para um software pode ser uma atividade t o complexa quanto a de projeto do pr prio software mas ela necess ria como nica forma de conduzir de forma eficiente e eficaz o processo de teste Os princ pios b sicos do teste de qualquer produto resultante de uma tarefa de engenharia s o e conhecida a fun o a ser desempenhada pelo produto testes s o executados para demonstrar que cada fun o completamente operacional este primeiro princ pio deu origem a uma importante abordagem de teste conhecida como o teste de caixa preta black box e com base no conhecimento do funcionamento interno do produto realiza se testes para assegurar de que todas as pe as destes est o completamente ajustadas e realizando a contento sua fun o abordagem originada por este segundo princ pio foi dado o nome de teste de caixa branca white box devido ao fato de que maior
9. o orientada ao processo a especifica o deve levar em conta o sistema do qual o software faz parte e o ambiente no qual o sistema vai operar a especifica o deve representar a vis o que os usu rios ter o do sistema uma especifica o deve ser operacional no sentido de que ela deve permitir mesmo num n vel de abstra o elevado algum tipo de valida o uma especifica o deve ser localizada e fracamente acoplada o que s o requisitos fundamentais para permitir a realiza o de modifica es durante a an lise de requisitos A figura 5 3 apresenta uma proposta de estrutura para o documento de Especifica o dos Requisitos do Software O documento inicia com uma Introdu o que apresenta as principais metas do software descrevendo o seu papel no contexto do sistema global As informa es prestadas nesta se o podem ser inclusive inteiramente extra das do documento de Plano de Software 5 6 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA 1 0 Introdu o 2 0 Descri o da Informa o 2 1 Diagramas de Fluxos de Dados 2 2 Representa o da Estrutura dos Dados 2 3 Dicion rios de Dados 2 4 Descri o das Interfaces do Sistema 2 5 Interfaces Internas 3 0 Descri o Funcional 3 1 Fun es 3 2 Descri o do Processamento 3 3 Restri es de Projeto 4 0 Crit rios de Valida o 4 1 Limites de Valida o 4 2 Classes de Testes 4 3 Expectativas
10. Identifica o dos Subsistemas Este passo busca definir os diferentes subsistemas que ir o compor o sistema computacional O particionamento realizado no passo anterior ser determinante para a obten o dos subsistemas uma vez que dependendo do crit rio utilizado cada grupo de requisitos poder definir um subsistema Por outro lado outros aspectos podem ser considerados para a defini o dos subsistemas particularmente aqueles relacionados a quest es do ambiente onde o sistema ser instalado Aloca o dos Requisitos O pr ximo passo a ser conduzido a aloca o dos requisitos aos subsistemas estabelecidos no passo anterior Pode parecer estranho considerar tal etapa quando se utiliza o resultado obtido no Particionamento dos Requisitos para realizar a Identifica o dos Subsistemas mas na verdade isto n o ocorre de forma t o imediata Por exemplo no caso da ado o de sistemas de prateleira para implementar algum subsistema as limita es do sistema adotado podem impor a realoca o de requisitos Especifica o das Funcionalidades Neste passo ser o definidas as fun es que ser o implementadas por cada subsistema No caso de um subsistema de software esta atividade pode ser encaminhada como parte da an lise de requisitos do mesmo Defini o das Interfaces dos Subsistemas Este um passo de extrema import ncia na condu o do projeto do sistema A defini o de forma precisa das interfaces entre os su
11. Sincroniza o de atividades concorrentes Quando um objeto deve realizar duas ou mais atividades de forma concorrente necess rio dividir split o controle em partes concorrentes e depois junt las merge completando as atividades antes da progress o do objeto para um pr ximo estado Uma seta que se ramifica para a divis o e uma seta com a extremidade ramificada para a jun o s o as representa es na nota o OMT 1 3 O mopero runcionaL O modelo funcional descreve os aspectos do sistema que dizem respeito com as transforma es de valores fun es mapeamentos restri es e depend ncias funcionais Este modelo captura o que o sistema faz sem levar em conta o como e o quando ele faz O modelo funcional representado por v rios diagramas de fluxo de dados DFDs que mostram as depend ncias entre valores e o calculo de valores de sa da a partir de valores de entrada e de fun es O modelo funcional inclui tamb m as restri es entre valores no modelo objeto 4 3 1 Diagramas de Fluxo de Dados O modelo funcional consiste de m ltiplos diagramas de fluxo de dados que especificam o significado de opera es e restri es Um diagrama de fluxo de dados DFD mostra a rela o funcional dos valores calculados pelo sistema incluindo valores de entrada sa da e armazenamento de dados internos Um DFD contem processos que transformam dados fluxos de dados que movimenta dados objetos atores que produzem
12. ca visam contem Atividade 9 Estima o para Implementa o o software derivada de acordo com um procedimento documentado descreve Atividade Figura 2 3 Exemplo de uma tarefa chave numa estrutura CMM e realizar uma visita da equipe organiza o para a realiza o de entrevistas e revis es de documenta o relacionadas ao processo de desenvolvimento as entrevistas e revis es dever o ser conduzidas pelas reas chave do CMM e pela an lise realizada sobre o question rio de maturidade e ao fim da visita a equipe elabora um relat rio enumerando os pontos fortes e os pontos fracos da organiza o em termos de processo de desenvolvimento de software e finalmente a equipe prepara um perfil de reas chave que indica as reas onde a organiza o atingiu n o atingiu os objetivos de cada rea p Engenharia de Software CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA CaP tuLo 3 Encenxaria De Sistemas COMPUTACIONAIS 1 INTRODU O Embora este curso tenha por objetivo a discuss o dos aspectos mais importantes relacionados ao desenvolvimento do software importante reconhecer o fato bvio de que o software n o consiste de um elemento aut nomo Para que suas fun es possam ser realizadas ele dever ser integrado a outros componentes especialmente elementos de hardware como processador circuitos de mem ria e outros Por esta raz o o soft
13. descri o pre o hora valor em dolar Para formalizar a descri o dos itens de dados utiliza se um conjunto de operadores que permita compor representa es que poder o ser mapeadas futuramente em estruturas de dados de uma dada linguagem de programa o Alguns dos operadores e construtores utilizados s o x a b x possui os elementos de dados a e b x a b x possui a ou b escolha x a x possui um elemento de dados opcional a x a x possui de zero a mais ocorr ncias de a x y a x possui y ou mais ocorr ncias de a x a z x possui z ou menos ocorr ncias de a x y a z x possui entre y e z ocorr ncias de a 7 3 R Descri o ne Processos Um outro aspecto importante na an lise de requisitos a Especifica o de Processos O objetivo da especifica o de processo auxiliar o analista a descrever de forma precisa o comportamento de alguns componentes do sistema ou processos definidos nos DFDs de n vel mais baixo A especifica o de processos pode ser realizada segundo diversas t cnicas mas uma das mais interessantes o texto estruturado o qual baseado num grupo limitado de verbos e substantivos organizados de modo a representar um compromisso entre a legibilidade e a precis o da especifica o O texto estruturado baseado principalmente nos seguintes elementos o um conjunto limitado de verbos de a o por exemplo calcular encontrar imprimir etc
14. es estabelecidas e adquirir um pacote comercial e modific lo de forma a que o novo software atenda s especifica es de projeto e encomendar o software a terceiros para que este atenda s especifica es Os procedimentos a efetuar para a aquisi o de um software v o depender da criticalidade das especifica es e do seu custo No caso de um software de custo relativamente baixo um software para PC por exemplo pode ser mais interessante adquir lo e fazer uma an lise de adequa o s especifica es de projeto No caso de softwares mais caros uma an lise mais cuidadosa se faz necess ria sendo que os procedimentos podem ser os seguintes desenvolver uma especifica o funcional e de desempenho para o software a projetar estabelecendo quando poss vel valores mensur veis realizar a estima o do custo interno de desenvolvimento e escolher um conjunto de pacotes comerciais que poderiam atender s especifica es desenvolver um esquema de an lise comparativa que permita confrontar as fun es chave das solu es alternativas avaliar cada pacote com base na qualidade do produto no suporte do vendedor garantia reputa o do vendedor e direcionamento do produto entrevistar usu rios do software colhendo suas opini es sobre os pacotes A partir dos resultados obtidos a decis o entre comprar ou desenvolver o software vai estar baseada nos seguintes crit rios e a data de entrega do
15. nfase dada ao desempenho interno do sistema ou do produto 2 2 1 O software e o teste de caixa preta Quando o procedimento de teste est relacionado ao produto de software o teste de caixa preta refere se a todo teste que implica na verifica o do funcionamento do software atrav s de suas interfaces o que geralmente permite verificar a operacionalidade de todas as suas fun es E importante observar que no teste de caixa preta a forma como o software est organizado internamente n o tem real import ncia mesmo que isto possa ter algum impacto na opera o de alguma fun o observada em sua interface 2 2 2 O software e o teste de caixa branca Um teste de caixa branca num produto de software est relacionado a um exame minucioso de sua estrutura interna e detalhes procedimentais Os caminhos l gicos definidos no software s o exaustivamente testados pondo prova conjuntos bem definidos de condi es ou la os Durante o teste o status do programa pode ser examinado diversas vezes para eventual compara o com condi es de estado esperadas para aquela situa o Apesar da import ncia do teste de caixa branca n o se deve guardar a falsa id ia de que a realiza o de testes de caixa branca num produto de software vai oferecer a garantia de 100 de corre o deste ao seu final Isto porque mesmo no caso de programas de pequeno e m dio porte a diversidade de caminhos l gicos pode atingir um n mero b
16. p CAP 2 QUALIDADE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA N veis de Maturidade F N indicam cont m V da Capabilidade Areas do Processo Chave x atingem organizados por Sud Fatores Objetivos Comuns cont m visam Tarefas Implementa o ou Institucionaliza o Chave V descrevem Infraestrutura ou Atividade Figura 2 2 Estrutura dos n veis CMM Como se pode notar na figura cada n vel de maturidade composto por diversas reas Chave as quais identificam um conjunto de atividades que quando realizadas conjuntamente permitem atingir os objetivos essenciais do n vel considerado aumentando a capabilidade do processo de desenvolvimento de software A Tabela 2 1 apresenta as reas chave associadas a cada um dos n veis do CMM exce o do n vel 1 como j foi explicado Os Fatores Comuns indicam o grau de implementa o ou institucionaliza o de uma dada rea Chave No modelo os Fatores Comuns foram definidos em n mero de cinco como mostra a Tabela 2 2 As Tarefas Chave correspondem s atividades que uma vez realizadas de modo conjunto contribuir o para o alcance dos objetivos da rea chave As tarefas chave descrevem a infra estrutura e as atividades que dever o ser implementadas para a efetiva implementa o ou institucionaliza o da rea chave As tarefas chave correspondem a uma senten a simples seguida por uma descri o d
17. um fator preponderante Isto consequ ncia de uma quest o cultural todos n s aprendemos a trabalhar sob o efeito da press o de tempo resultante de uma pressa nem sempre justificada conduzindo na maior parte das vezes a prazos totalmente irreal sticos definidos por quem n o tem um grau de envolvimento significativo no projeto Na pr tica a defini o de cronogramas dos projetos feita de maneira arbitr ria os riscos do projeto s s o considerados quando eles transformaram se em problemas reais a organiza o da equipe nem sempre clara e feita de forma consciente Neste cap tulo ser o discutidos alguns pontos fundamentais para que o projeto de desenvolvimento de um software seja conduzido de forma a obter resultados satisfat rios em termos de produtividade do processo e qualidade do produto 2 AN LISE DE RISCOS A an lise dos riscos uma das atividades essenciais para o bom encaminhamento de um projeto de software Esta atividade est baseada na realiza o de quatro tarefas conduzidas de forma sequencial a identifica o a proje o a avalia o e a administra o 2 1 R Inenvrica o Dos Riscos Nesta primeira tarefa o objetivo que sejam levantados da parte do gerente e dos profissionais envolvidos no projeto todos os eventuais riscos aos quais este ser submetido Nesta identifica o riscos de diferentes naturezas podem ser detectados riscos de projeto os quais est o associa
18. AN LISE E PROJETO ORIENTADOS A OBJETOS PROF Vit rio BRUNO MAZZOLA armazenamento Destaca se que atores e armazenadores de dados s o objetos que se diferenciam pelo seu comportamento e uso atores podem ainda serem implementados como dispositivos externos e armazenadores como arquivos Diagramas de fluxo de dados aninhados Um DFD particularmente til para mostrar a funcionalidade de alto n vel de um sistema e sua quebra em unidades funcionais menores Um processo pode ser expandido num outro DFD no qual as entradas e sa das do processos o s o tamb m no novo diagrama Eventualmente o anhinhamento de diagramas termina com fun es simples que devem ser especificadas como opera es Fluxos de controle Um DFD n o mostra quais caminhos s o executados e em que ordem Decis es e sequenciamento s o quest es de controle que fazem parte do modelo din mico As vezes pode ser til introduzir o fluxo de controle no DFD O fluxo de controle uma vari vel booleana que indica quando um processo pode ser realizado o fluxo de controle representado por uma linha pontilhada no DFD que vai de um processo que gera uma vari vel booleana ao processo a ser controlado n o um valor de entrada para o processo ele mesmo 4 3 2 Especificando opera es Processos em DFD devem eventualmente ser implementados como opera es sobre objetos Para cada n vel baixo um processo at mico uma opera o Processos de n vel elevado podem
19. Exemplos de objetos o par grafo de um documento a janela num computador o aluno Pedro neste curso o carro do Jo o O conjunto de valores associados s propriedades do objeto definem o estado deste o comportamento descreve as mudan as do estado do objeto interagindo com o seu mundo externo atrav s das opera es realizadas pelo objeto 9 2 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF Vit rio BRUNO MAZZOLA As se es que seguem apresentam outras defini es relacionadas tecnologia de objetos que s o de extrema import ncia compreens o das atividades e metodologias baseadas em objetos 2 2 Casse Uma classe o agrupamento de objetos com a mesma estrutura de dados definida pelos atributos ou propriedades e comportamento opera es RBP91 Uma classe uma abstra o que descreve as propriedades importantes para uma aplica o e n o leva em conta as outras Exemplos de classes Par grafo Janela Aluno Carro Cada classe descreve um conjunto possivelmente infinito de objetos individuais Cada objeto uma inst ncia de classe Cada inst ncia de classe tem seu pr prio valor para cada um dos atributos da classe mas compartilha os nomes e as opera es com as outras inst ncias de classe 2 3 Orienta o a oBJetos Ela se caracteriza principalmente pela abstra o encapsulamento heran a e polimorfismo 2 4 Asta o A abstra o consiste em enfocar os aspectos mais import
20. Na realidade o que vai determinar o esfor o a ser dispendido com os testes ser o os requisitos do pr prio software Softwares concebidos para aplica es cr ticas onde as consequ ncias dos erros podem ser catastr ficas seja em termos de perdas humanas ou materiais v o exigir um esfor o muito maior em termos de teste do que as aplica es mais cl ssicas de automa o de escrit rio por exemplo 3 3 R Representa o Do CRonocrama A defini o do cronograma uma das tarefas mais dif ceis de se definir na etapa de planejamento do software O planejador deve levar em conta diversos aspectos relacionados ao desenvolvimento como a disponibilidade de recursos no momento da execu o de uma dada tarefa as interdepend ncias das diferentes tarefas a ocorr ncia de poss veis estrangulamentos do processo de desenvolvimento e as opera es necess rias para agilizar o processo identifica o das principais atividades revis es e indicadores de progresso do processo de desenvolvimento etc A forma de representa o dos cronogramas depende da pol tica de desenvolvimento adotada mas pode ser apresentada numa forma geral por um documento do tipo apresentado na figura 4 5 As unidades de tempo consideradas no projeto dias semanas meses etc s o anotadas na linha superior da folha de cronograma As tarefas do projeto as atividades e os indicadores de progresso s o definidos no coluna da esquerda O tra o horizontal
21. Nesta etapa os requisitos definidos na etapa anterior devem servir de refer ncia para a obten o da representa o do software Neste cap tulo ser o apresentados os principais aspectos relativos ao projeto de software como etapa fundamental para a obten o de um software de qualidade Ser o apresentadas algumas das t cnicas cl ssicas de projeto assim como a aplica o de t cnicas de projeto a aspectos mais inovadores do desenvolvimento de software como as interfaces homem m quina e os sistemas de tempo real 2 O PROCESSO DE PROJELO 2 1 Projetos PreLimmar e DetaLHaDo A etapa de projeto caracterizada pelo conjunto de atividades que vai permitir traduzir os requisitos definidos na etapa anterior em uma representa o do software a ser constru do Na sua forma mais cl ssica o primeiro resultado obtido no projeto uma vis o da estrutura do software em termos de componentes sendo que a partir de procedimentos de refinamento chega se a um n vel de especifica o bastante pr xima da codifica o do programa Do ponto de vista do gerenciamento do processo de desenvolvimento a etapa de projeto conduzida basicamente em dois principais est gios o projeto preliminar o qual permite estabelecer a partir dos requisitos a arquitetura do software e da informa o relacionada o projeto detalhado o qual permite aperfei oar a estrutura do software e definir representa es algor tmicas de seus componentes
22. Pessoa Pessoa Clara M rcio idade integer 24 38 Classe com Objetos com atributos valores Figura 9 2 Ilustra o de Atributos e Valores Uma opera o pode ser aplicada a ou por objetos numa classe A mesma opera o pode se aplicar a v rias classes diferentes polimorfismo Um m todo a implementa o de uma opera o para uma classe Quando uma opera o tem m todos em v rias classes eles devem ter a mesma assinatura em n mero e tipos de argumentos As opera es se encontram na terceira parte da caixa como ilustrado na figura 9 3 Cada opera o pode ser seguida de detalhes opcionais tais como lista de argumentos colocada entre par nteses ap s o nome separados por e tipo de resultado precedido por A nota o generalizada para classes de objetos se encontra na figura 9 4 A Objeto esses Arquivo Geom trico nome identificador or idade tamanho bytes posi o ltima altera o move delta vetor seleciona p ponto roda ngulo muda emprego muda end imprime Figura 9 3 Opera es com Objetos Nome da Classe nome atributo 1 tipo dado 1 valor default 1 nome atributo 2 tipo dado 2 valor default 2 nome opera o 1 lista argumentos 1 tipo result 1 nome opera o 2 lista argumentos 2 tipo result 2 Figura 9 4 Generaliza o da nota o de modelagem de objetos 4 1 2 Liga es e associa es A liga o ou link uma
23. RIO BRUNO MAZZOLA Existem basicamente dois tipos de diagramas definidos no modelo SADT os actigramas e os datagramas Nos actigramas os blocos designam as atividades relacionadas ao sistema sob an lise sendo que os arcos representam os fluxos de dados entre as atividades Os actigramas s o de certo modo um equivalente dos diagramas de fluxos de dados dentro do modelo SADT Nos datagramas os blocos especificam objetos de dados e os arcos as atividades ou a es definidas sobre estes dados Os actigramas e os datagramas t m estabelecida entre si uma rela o de dualidade Na pr tica os actigramas s o utilizados com muito mais frequ ncia que os datagramas Entretanto o uso de datagramas assume um n vel elevado de import ncia por duas raz es principais e para especificar todas as atividades relacionadas com um dado objeto de dado para verificar a coer ncia de um modelo SADT pela constru o de datagramas a partir de actigramas A forma geral dos blocos de um actigrama e de um datagrama apresentada na figura 5 13 Em 5 13 a mostrado o bloco relacionado a um actigrama Na sua forma geral os poss veis fluxos de dados s o os de entrada de sa da de controle e o mecanismo As sa das de um bloco de actigrama podem representar entradas ou controles de um outro bloco do mesmo actigrama e dever o desta forma ser conectadas a outros blocos do actigrama ou ao ambiente externo As entradas e controles de um bloco de
24. as dimens es etc a leitura um outro processo importante na comunica o usu rio software apesar da grande tend ncia em se utilizar recursos gr ficos nas interfaces homem m quina os diferentes n veis de habilidades das pessoas s o um outro aspecto de import ncia no projeto de uma interface de software o projetista deve ter a 6 12 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA preocupa o de dirigir a interface para o usu rio t pico do software uma interface que seja orientada e adequada ao uso por um engenheiro pode representar grandes dificuldades de utiliza o por parte de um trabalhador inexperiente no caso de softwares de aplica o vertical destinados a reas de aplica o espec ficas importante que a linguagem utilizada suporte termos e conceitos pr prios da rea as tarefas a realizar com a introdu o do software s o em grande parte dos casos as mesmas que eram realizadas no sistema n o automatizado a introdu o do software para automatizar um sistema raramente viabiliza a realiza o de novas tarefas mas permite que as tar efas antes realizadas manualmente possam vir a ser realizadas de forma mais eficiente e menos dispendiosa em muitos casos o software assume tarefas que eram realizadas manualmente sendo assim as tarefas essenciais do sistema deve ser um outro aspecto a ser considerado no projeto da interface 6 2 Aspectos DOS PROJetos De Interr
25. e medida que os m dulos s o integrados os testes v o sendo realizados e quando uma bateria de testes terminada os stubs v o sendo substitu dos por m dulos reais e finalmente pode ser realizado um teste de regress o que tem por objetivo garantir que novos erros n o tenham sido introduzidos durante o processo de descida 8 9 CAP 8 TESTE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 5 3 Imecra o Bortom UP O teste de integra o segundo a abordagem bottom up sugere uma integra o igualmente incremental mas no sentido inverso ou seja dos n veis mais baixos para o n vel mais alto Como ilustrado pela figura 8 4 a constru o se inicia a partir dos m dulos ditos at micos os m dulos do n vel mais baixo facilitando de certa forma integra o pois quando se para de um n vel para um superior os m dulos subordinados necess rios para testar a integra o neste novo n vel est o dispon veis e testados Os passos normalmente executados nesta estrat gia de teste s o e os m dulos de n vel mais baixo s o agrupados em clusters ou constru es que executam uma fun o espec fica do software um driver constru do para coordenar a entrada e a sa da dos casos de teste e o cluster testado os drivers s o removidos e os clusters s o combinados com m dulos dos n veis superiores para uma nova etapa at que todo o programa tenha sido remontado
26. encaminhadas desde a etapa de An lise de Requisitos Naquela etapa dado o pontap inicial para a defini o das estruturas de dados e dos componentes de software A solu o encaminhada ao longo do projeto atrav s da defini o de um ou mais elementos de software que solucionar o uma parte do problema global E importante lembrar que n o existe t cnica de projeto que garanta a unicidade de solu o a um dado problema Diferentes solu es em termos de arquitetura podem ser derivadas a partir de um mesmo conjunto de requisitos de software A grande dificuldade concentra se em definir qual a melhor op o em termos de solu o 3 5 Hierarquia De ControLe A hierarquia de controle nada mais do que a representa o usualmente sob a forma hierarquizada da estrutura do software no que diz respeito aos seus componentes O objetivo n o apresentar detalhes procedimentais ou de sequenciamento entre processos mas de estabelecer as rela es entre os diferentes componentes do software explicitando os n veis de abstra o refinamento aos quais eles pertencem O modo mais usual de apresentar a hierarquia de controle utiliza uma linguagem gr fica normalmente em forma de rvore como mostra a figura 6 1 Com rela o estrutura de controle importante apresentar algumas defini es de medi o Utilizando a figura 6 1 como refer ncia poss vel extrair alguns conceitos a profundidade a qual est associad
27. o estruturas de controle j conhecidas da programa o estruturada IF THEN ELSE DO WHILE CASE etc gt elementos de dados definidos no Dicion rio de Dados E fas CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA Um exemplo de especifica o de processo apresentada abaixo representando um dos processos definidos no DFD da figura 5 7 PROCESSO Calcula_Desconto IF Empregado isento de descontos THEN Sal rio L quido igual a Sal rio Bruto ELSE IF Sal rio Bruto maior que X THEN Desconto de 25 ELSE IF Sal rio Bruto maior que Y THEN Desconto de 20 ELSE Desconto de 15 FIM Calcula_Desconto Outras t cnicas podem ser utilizadas para a especifica o de um processo como os fluxogramas as tabelas de decis o etc 7 4 Representa o Da Rela o entre os Danos Um quarto elemento relacionado an lise estruturada objetiva o estabelecimento de uma rela o entre os diferentes dados definidos no DFD e no dicion rio de dados Uma forma de representar estas rela es atrav s dos diagramas Entidade Rela o E uma ferramenta gr fica que permite definir as rela es entre as diferentes entidades definidas num dado sistema Fugindo um pouco do exemplo da figura 5 7 apresentado na figura 5 8 um exemplo de diagrama Entidade Rela o para um sistema de tr fego a reo Como se pode notar no exemplo os ret ngulos representam as entidades do sistema e os losangos as
28. CAP 8 TESTE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA preced ncia aritm tica incorreta opera es envolvendo dados de tipos diferentes inicializa o incorreta erros deprecis o representa o incorreta de uma express o la os mal definidos compara o de diferentes tipos de dados operadores l gicos utilizados incorretamente etc 4 1 5 O teste de caminhos de tratamento de erros desej vel que um projeto de software estabele a caminhos de tratamento de erros para as unidades que o comp em permitindo que os problemas que venham a ocorrer durante a utiliza o de um programa especialmente no caso de programas interativos possam ser recuperados e a execu o do programa possa ser retomada normalmente Entretanto embora muitos projetistas e programadores tenham o h bito de inserir este tipo de tratamento raramente eles s o testados E importante que estes caminhos venham a ser testados tamb m para detectar os erros mais comuns deste tipo de tratamento que s o e descri o incompreens vel do erro por exemplo erro 1356 descri o incorreta do erro o erro indicado n o corresponde ao erro ocorrido e ocorr ncia de interven o do sistema antes da indica o ou tratamento do erro pela unidade e processamento incorreto das condi es de exce o por exemplo tratar ou idicar a ocorr ncia de um erro que n o aconteceu e descri o imprecisa do erro n o informa como localizar ou evit
29. Linauacens ne terceira Gera o Nesta classe encaixam se as chamadas linguagens de programa o estruturada surgidas em meados dos anos 60 O per odo compreendido entre a d cada de 60 e a de 80 foi bastante produtivo no que diz respeito ao surgimento de linguagens de programa o o que permitiu o aparecimento de uma grande quantidade de linguagens as quais podem ser organizadas da seguinte forma as linguagens de uso geral as quais podem ser utilizadas para implementa o de programas com as mais diversas caracter sticas e independente da rea de aplica o considerada encaixam se nesta categoria linguagens como Pascal Modula 2 e C as linguagens especializadas as quais s o orientadas ao desenvolvimento de aplica es espec ficas algumas das linguagens que ilustram esta categoria s o Prolog Lisp e Forth as linguagens orientadas a objeto que oferecem mecanismos sint ticos e sem nticos de suporte aos conceitos da programa o orientada a objetos alguns exemplos destas linguagens s o Smalltalk Eiffel e C IM Lnauacens ne Quarta Gera o As linguagens de quarta gera o surgiram como forma de aumentar o grau de abstra o na constru o de programas Uma caracter stica comum nestas linguagens a especifica o do programa sem a necessidade de express o de detalhes algor tmicos de processamento E evidente que devido a esta caracter stica imposs vel que uma linguagem possa ser utilizada para
30. No contexto dos projetos preliminar e detalhado uma conjunto de atividades t cnicas de projeto s o desenvolvidas Num ponto de vista mais gen rico pode se destacar os projetos arquiteturais procedimentais e de dados Em projetos mais recentes e particularmente naqueles envolvendo interatividade com o usu rio o projeto de interfaces tem assumido um papel de fundamental import ncia sendo considerada uma atividade do mesmo n vel dos demais projetos 6 2 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 2 2 Caracter sticas DeseJ veIs NUM PROJETO De SOFtWARE A obten o de um software de boa qualidade est relacionada ao sucesso de cada uma das etapas do seu desenvolvimento No que diz respeito etapa de projeto poss vel detectar algumas das caracter sticas desej veis e deve apresentar um organiza o hier rquica definida de modo a utilizar racionalmente todos os elementos de software e deve basear se em princ pios de modularidade ou seja propor um particionamento do software em elementos que implementem fun es ou subfun es do software deve conduzir a uma defini o em m dulos com alto grau de independ ncia como forma de facilitar as tarefas de manuten o ao longo da vida do software deve ser fiel especifica o dos requisitos definida na etapa anterior 3 ASPECLOS FUNDAMENTAIS DO PROJETO Durante esta etapa importante que alguns conceitos sejam levados em cont
31. O desenvolvimento deste prot tipo feito obedecendo realiza o das diferentes etapas j mencionadas a saber a an lise de requisitos o projeto a codifica o e os testes sendo que n o necessariamente estas etapas sejam realizadas de modo muito expl cito ou formal Este prot tipo pode ser oferecido ao cliente em diferentes formas a saber e prot tipo em papel ou modelo execut vel em PC retratando a interface homem m quina capacitando o cliente a compreender a forma de intera o com o software e um prot tipo de trabalho que implemente um subconjunto dos requisitos indicados e um programa existente pacote que permita representar todas ou parte das fun es desejadas para o software a construir Colocado disposi o do cliente o prot tipo vai ajud lo a melhor compreender o que ser o sistema desenvolvido Al m disso atrav s da manipula o deste prot tipo poss vel validar ou reformular os requisitos para as etapas seguintes do sistema Este modelo ilustrado na figura 1 4 apresenta algumas caracter sticas interessantes tais como e um modelo de desenvolvimento interessante para alguns sistemas de grande porte os quais representem um certo grau de dificuldade para exprimir rigorosamente os requisitos e atrav s da constru o de um prot tipo do sistema poss vel demonstrar a realizabilidade do mesmo e poss vel obter uma vers o mesmo simplificada do que ser o sistema com um
32. a programa o de uso geral sendo normalmente destinadas a aplica es em dom nios espec ficos Dentro desta classe poss vel encontrar diferentes categorias de linguagens 4 4 1 Linguagens de consulta Nesta categoria encaixam se as linguagens orientadas a aplica es conjuntas de bancos de dados permitindo que o usu rio especifique opera es sobre os registros num alto n vel de sofistica o Algumas linguagens nesta categoria incorporam recursos de 7 71 CAP 7 LINGUAGENS DE PROGRAMA O PROF Vit rio BRUNO MAZZOLA interpreta o de linguagem natural de modo que o usu rio pode manipular a informa o no n vel mais alto de abstra o poss vel 4 4 2 Linguagens geradoras de programas Nesta categoria est o as linguagens que permitem que o programador especifique o programa considerando constru es e instru es num elevado n vel de abstra o sendo que os programas ser o obtidos em c digo fonte de uma linguagem de programa o de terceira gera o 4 4 3 Outras linguagens Nesta categoria pode se considerar as linguagens desenvolvidas nos ltimos anos como por exemplo as linguagens de especifica o formal referenciadas no cap tulo 6 as linguagens de prototipa o e os ambientes de programa o presentes em computadores pessoais planilhas bancos de dados hypertexto etc 5 ESTILO De CODIFICA O A escolha de uma linguagem de programa o adequada que suporte
33. actigrama dever o similarmente ser sa das de outros blocos ou dados do ambiente externo Os controles de uma atividade s o dados utilizados na atividade mas que n o s o modificados por ela Os mecanismos s o os elementos necess rios realiza o daquela atividade como por exemplo os processadores Um exemplo de representa o por actigrama apresentado na figura 5 14 No exemplo o processo de escrita de um texto a atividade representada por um bloco rotulado pelo verbo redigir O dado de entrada da atividade a id ia e a sa da o texto Dados Controle Atividades de Controle Dados Dados Atividade Atividades Entrada ATIVIDADE Sa da Ed DADO Sa da Mecanismo Dispositivo de Armazenamento a b Figura 5 13 Blocos de composi o de um actigrama a e de um datagrama b 518 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA sintaxe da estilo de linguagem reda o Id ia Texto papel l pis Figura 5 14 Exemplo de representa o em SADT o processo de reda o de um texto Como controle tem se a sintaxe da linguagem e o estilo de reda o Finalmente os mecanismos considerados s o o l pis e o papel Num datagrama as entradas de um bloco s o as atividades que geraram o dado representado pelo bloco as sa das s o as atividades que v o utilizar o objeto de dado Os controles s o as condi es nas quais o objeto de dado ser ativado Os mecanismos s o os elemento
34. algum recurso pode ser imposs vel instalar completamente o novo sistema sem desativar o antigo e Obst culos f sicos instala o do sistema s o problemas muito comuns nesta etapa aus ncia de pontos de energia ou tubula o apropriada falta de sistema 312 CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA de ar condicionado s o exemplos de obst culos comumente encontrados na instala o de sistemas computacionais 3 6 Rerva o Do Sistema Uma vez instalado o sistema dever ser ativado Uma etapa de apresenta o e treinamento relativo utiliza o pode estar associada ativa o do sistema Os problemas que podem ocorrer nesta etapa s o os mais diversos No caso de sistemas que dever o operar conjuntamente a outros sistemas existentes problemas de incompatibilidade podem ocorrer e a dificuldade de resolu o destes problemas pode provocar grandes atrasos sua coloca o em opera o Outra fonte de problemas pode ser a inadequa o ou a m utiliza o das interfaces de operador do novo sistema Muitos erros de opera o poder o ser cometidos at que o operador crie intimidade com o novo sistema 3 7 yoLu o Do Sistema Os grandes sistemas computacionais s o desenvolvidos para funcionar durante longos per odos tempo E inevit vel que durante este per odo ocorram problemas que imponham modifica es no sistema As raz es que podem conduzir a esta n
35. ao nome do bloco pai As setas que apresentam as suas extremidades livres num dado diagrama correspondem s interfaces do bloco pai Ap s a verifica o de que todas as setas com extremidades livres correspondem totalidade das interfaces do bloco pai elas devem ser rotuladas com as letras C O e M designando uma entrada um controle uma sa da ou um mecanismo respectivamente sendo que a letra deve ser seguida de um n mero que indique a sua posi o geom trica relativa no bloco pai A ordena o das setas feita num diagrama de cima para baixo e da esquerda para e direita Uma seta rotulada por C3 corresponde ao terceiro controle do bloco pai 5 20 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA A0 E R A3 a A33 Figura 5 16 Ilustra o das refer ncias aos diagramas e aos blocos Por outro lado quando realizado o refinamento de um dado bloco bloco pai as interfaces n o ser o necessariamente vistas da mesma forma que no bloco pai Um exemplo disto apresentado figura 5 19 onde um controle C2 no bloco pai corresponde a uma entrada de um dos blocos do diagrama filho An AO t tulo diagrama A1 t tulo diagrama A2 t tulo diagrama A1 A2 A3 A3 t tulo diagrama A31 t tulo diagrama A32 t tulo diagrama A33 t t
36. cada vez mais da Implementa o que o n vel mais baixo de abstra o 3 2 Rermamento O refinamento surgiu na forma de uma t cnica de projeto a t cnica de Refinamentos Sucessivos proposta por Wirth em 1971 Esta t cnica sugere como ponto de partida a defini o da arquitetura do software a ser desenvolvido sendo que esta vai sendo refinada sucessivamente at atingir n veis de detalhes procedimentais Este processo d origem a uma hierarquia de representa es onde uma descri o macrosc pica de cada fun o vai sendo decomposta passo a passo at se obter representa es bastante pr ximas de uma linguagem de implementa o Este processo bastante similar ao processo utilizado em diversas t cnicas de An lise de Requisitos como o DFD e o SADT sendo que a diferen a fundamental est nos n veis de detalhamento atingidos nesta etapa 6 3 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 3 3 Mopuarmane O conceito de modularidade tem sido utilizado j h bastante tempo como forma de obten o de um software que apresente algumas caracter sticas interessantes como a facilidade de manuten o Este conceito apareceu como uma solu o aos antigos softwares monol ticos os quais representavam grandes dificuldades de entendimento e conseq entemente para qualquer atividade de manuten o A utiliza o do conceito de modularidade oferece resultados a curto prazo uma vez que ao dividir
37. de mem ria uso em diferentes vers es de processadores quantidade de bloqueios encontrados num dado per odo de utiliza o etc TM O veste De Desempenxo Este tipo de teste consiste em verificar se os requisitos de desempenho est o sendo atendidos para o sistema como um todo Este aspecto que pode n o Ter grande import ncia em alguns sistemas quais torna se cr tico em aplica es envolvendo sistemas embarcados e sistemas multim dias que pertencem classe dos sistemas tempo real Nestes sistemas o n o atendimento a um requisito de tempo pode afetar de forma irrevers vel a fun o do sistema e no caso de alguns sistemas os chamados sistemas cr ticos a n o realiza o desta fun o ou o n o atendimento a estes requisitos temporais pode resultar em preju zos catastr ficos risco a vidas humanas ou grandes preju zos financeiros Os testes de desempenho s o realizados normalmente com o aux lio de instrumenta o de hardware e de software que permitam medir como os recursos do sistema est o sendo utilizados O uso da instrumenta o pode facilitar a coleta de dados e o registro de status do sistema nos seus diferentes pontos de funcionamento g i4 Engenharia de Software CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF Vit rio BRUNO MAZZOLA Car tuLo 9 An Lise e ProJeto ORIENTADOS A OBJeros 1 INTRODU O Existem muitas defini es para o que se chama em desenvolvimento de so
38. desenvolvidos em hardware e em software permitindo o encaminhamento das atividades relativas s diferentes engenharias normalmente conduzidas em paralelo Big CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA Na maior parte dos sistemas atuais comum que os componentes de hardware incluam um ou mais computadores e o software associado Isto se justifica pela queda constante nos pre os de equipamentos computacionais permitindo a substitui o de outras alternativas pelos sistemas computacionais al m das vantagens de tais equipamentos particularmente para tarefas de controle e supervis o No n vel de projeto arquitetural nem sempre importante definir que fun es ser o executadas por software ou por hardware O mais importante definir subsistemas com base nas fun es a serem executadas pelo sistema A defini o sobre a forma como cada fun o ser implementada em software ou em hardware pode ser feita numa etapa posterior levando em conta n o apenas fatores t cnicos Por exemplo a exist ncia ou n o de um componente de hardware que implemente adequadamente uma dada fun o pode ser determinante para definir se esta fun o dever ser implementada em hardware ou software La Componentes Funcionais Durante a realiza o das diferentes etapas que caracterizam o desenvolvimento de um sistema computacional particularmente na etapa de defini o dos subsistemas diferentes cat
39. do problema Finalmente uma linha dupla preenchida com um r tulo permite expressar dep sitos de dados A figura 5 5 apresenta os s mbolos b sicos de um DFD Esta representa o pode ser adotada seja para o sistema seja para o software como elemento de um sistema sendo poss vel definir diversas parti es como forma de apresentar diferentes n veis de detalhamento do software ou do sistema Informa o Entidade de Sa da externa Informa o Entidade de Entrada externa Entidade Sistema Computacional externa Informa o de Sa da Entidade gt externa Entidade externa Informa o de Entrada Informa o de Sa da Figura 5 4 Formato gen rico de um DFD lt identificador gt Processo de Transforma o lt r t l gt tem de dado gt Entidade Externa lt r tulo gt Dep sito de dados Figura 5 5 S mbolos gr ficos de um DFD 5 10 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA O primeiro n vel de representa o ou n vel 0 do DFD o modelo fundamental do sistema ou modelo de conte do utilizado para representar o elemento de software global como um nico c rculo e as informa es de entrada e sa da representadas pelas setas rotuladas entrando e saindo do c rculo Neste primeiro n vel s o representados por ret ngulos os elementos externos ao software que geram e consomem as informa es A medida que
40. do funcionamento que dependem da intera o dos demais elementos do sistema Apresentada uma breve descri o destes tipos de teste informa es mais detalhadas ser o apresentadas nas se es que seguem Y teste De UNIDADE Li Aspectos a serem testados A figura 8 1 ilustra a forma como s o desenvolvidos os testes de unidade Os aspectos verificados no contexto deste teste normalmente s o e a interface em busca de erros de passagem de dados para dentro e para fora do m dulo e as estruturas de dados locais para se prover a garantia de que todos os dados armazenados localmente mant m sua integridade ao longo da execu o do m dulo M dulo Interface Estrutura de dados locais Condi es de limite Caminhos independentes Caminho de tratamento de erros Casos de Teste Figura 8 1 Teste de Unidade e as condi es limite que permitem verificar que o m dulo executa respeitando os valores m ximos e m nimos estabelecidos para seu processamento e os caminhos independentes ou caminhos b sicos da estrutura de controle s o analisados para se ter garantia de que todas as instru es do m dulo foram executadas pelo menos uma vez e finalmente os caminhos de tratamento de erros se existirem ser o testados para observar a robustez do m dulo 8 5 CAP 8 TESTE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 4 1 1 O teste de i
41. e consomem dados objetos armazenamento de dados que estocam os dados Processos Um processo transforma valores de dados Um processo implementado como um m todo de uma opera o de uma classe de objetos O objeto alvo usualmente um dos fluxos de entrada especialmente se a mesma classe de objeto tamb m um fluxo de sa da Em alguns casos o objeto alvo impl cito Fluxos de dados Um fluxo de dados conecta a sa da de um objeto ou de um processo a entrada de um outro objeto ou processo Ele representa um valor de daos intermedi rio num calculo O valor permanece sem mudan a no fluxo de dados Atores Um ator um objeto ativo que conduz o diagrama de fluxo de dados produzindo ou consumindo valores Atores s o ligados as entradas e sa das de um diagrama de fluxo de dados Eles podem serem vistos como fontes e receptores de dados Estado 1 a o atividade evento atributos 1 condi o a o entrada a o 2 sa da a o3 evento a o4 evento atributos2 Classe de Objeto Figura 9 16 Ilustra o da nota o extendida dos diagramas de estado Armazenadores de dados Um armazenador de dados um objeto passivo do diagrama de fluxo de dados que armazena dados para uma cesso futuro gt como no caso de um ator um armazenador n o gera opera es sobre ele mesmo mas simplesmente responde a pedidos para armazenar e acessar dados O acesso pode ser feito em ordem diferente do gs CAP 9
42. em subsistemas a partir das no es de camadas subdivis o horizontal e de parti es subdivis o vertical identificar a concorr ncia inerente ao problema e definir as tarefas concorrentes alocar os subsistemas a processadores e tarefas escolher uma abordagem para gerenciar os armazenadores de dados determinar os mecanismos para manusear o acesso aos recursos globais escolher a implementa o do controle no software determinar o manuseio das condi es limites estabelecer as prioridades entre os compromissos 6 2 Projeto DO OBJetro A fase de projeto de objeto determina as defini es completas das classes e associa es utilizadas na implementa o bem como as interfaces e os algoritmos dos m todos utilizados par implementar as opera es Nesta fase s o adicionados objetos internos para a implementa o e otimizado as estruturas de dados e os algoritmos O projetista dever escolher entre v rias formas de implementa o levando em conta quest es como minimiza o do tempo de execu o da mem ria e outras medidas de custo A otimiza o do projeto deve ainda levar em conta as facilidades de implementa o manuten o e expans o Durante o projeto do objeto o projetista deve realizar os passos seguintes combinar os tr s modelos para obter as opera es sobre as classes projetar os algoritmos para implementar as opera es otimizar os caminhos de acesso aos dados implementar o controle para as
43. extensibilidade etc J os fatores de qualidade internos s o aqueles que est o mais relacionados vis o de um programador particularmente aquele que vai assumir as tarefas de manuten o do software Nesta classe encontram se fatores como modularidade legibilidade portabilidade etc N o dif cil verificar que normalmente os fatores mais considerados quando do desenvolvimento do software s o os externos Isto porque uma vez que o objetivo do desenvolvimento do software satisfazer ao cliente s o estes fatores que v o assumir um papel importante na avalia o do produto da parte do cliente claro No entanto tamb m n o dif cil concluir que s o os fatores internos que v o garantir o alcance dos fatores externos 2 2 Fatores De QuaLipaDe 22 1 Corre o a capacidade dos produtos de software de realizarem suas tarefas de forma precisa conforme definido nos requisitos e na especifica o E um fator de suma import ncia em qualquer categoria de software Nenhum outro fator poder compensar a aus ncia de corre o N o interessante produzir um software extremamente desenvolvido do ponto de vista da interface homem m quina por exemplo se as suas fun es s o executadas de forma incorreta E preciso dizer por m que a corre o um fator mais facilmente afirmado do que alcan ado O alcance de um n vel satisfat rio de corre o vai depender principalmente da formaliza o dos r
44. ferramentas da Engenharia de Software o software existente sofre uma reforma geral cujo objetivo aumentar a sua qualidade e atualiz lo com respeito s novas tecnologias de interface e de hardware Eu E Engenharia de Software CAP 2 QUALIDADE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA CaP tuLo 2 QUALIDADE De SOFTWARE 1 INTRODU O Como foi mencionado no cap tulo anterior o papel da Engenharia de Software principalmente fornecer m todos e ferramentas para o desenvolvimento do software de qualidade e a baixo custo O fator qualidade um dos aspectos importantes que deve ser levado em conta quando do desenvolvimento do software Para isto necess rio que se tenha uma defini o precisa do que um software de qualidade ou pelo menos quais s o as propriedades que devem caracterizar um software desenvolvido segundo os princ pios da Engenharia de Software Um outro aspecto importante aquele relacionado avalia o e ao aprimoramento do processo de desenvolvimento de software de uma organiza o Nesta linha foi desenvolvido pelo SEI Software Engineering Institute um modelo que permite definir par metros para a an lise desta quest o nas corpora es o modelo CMM Capability and Maturity Model cujas linhas gerais ser o descritas na se o 5 2 DEFINI O DE SOFTWARE DE QUALIDADE Primeiramente importante discutir o conceito de software de qualidade Segundo a Associa o Franc
45. in cio do projeto no in cio do projeto pressupor que a rotatividade vai ocorrer e prever a possibilidade de substitui o de pessoas quando estas deixarem a equipe organizar equipes de projeto de forma que as informa es sobre cada atividade sejam amplamente difundidas e definir padr es de documenta o para garantir a produ o de documentos de forma adequada realizar revis es do trabalho entre colegas de modo que mais de uma pessoa esteja informado sobre as atividades desenvolvidas definir um membro da equipe que possa servir de backup para o profissional mais cr tico importante observar que a implementa o destas a es pode afetar tamb m os prazos e o custo global do projeto Isto significa que necess rio poder avaliar quando os custos destas a es podem ser ultrapassados pela ocorr ncia dos fatores de risco Num projeto de grande dimens o de 30 a 40 fatores de risco podem ser identificados se para cada fator de risco sete a es forem definidas a administra o dos riscos pode tornar se um projeto ela mesma Por esta raz o necess rio que uma prioriza o dos riscos seja efetuada atingindo normalmente a 20 de todos os fatores levantados Todo o trabalho efetuado nesta tarefa registrado num documento denominado Plano de Administra o e Monitora o de Riscos o qual ser utilizado posteriormente pelo gerente de projetos particularmente para a defini o do Plano de Projeto que
46. lise de Requisitos uma tarefa que envolve antes de tudo um trabalho de descoberta refinamento modelagem e especifica o das necessidades e desejos relativos ao software que dever ser desenvolvido Nesta tarefa tanto o cliente como o desenvolvedor v o desempenhar um papel de grande import ncia uma vez que caber ao primeiro a formula o de modo concreto das necessidades em termos de fun es e desempenho enquanto o segundo atua como indagador consultor e solucionador de problemas Esta etapa de suma import ncia no processo de desenvolvimento de um software principalmente porque ela estabelece o elo de liga o entre a aloca o do software a n vel de sistema realizada na etapa de Engenharia de Sistema e o projeto do software Desta forma ela permite que o engenheiro de sistemas especifique as necessidades do software em termos de fun es e de desempenho estabele a as interfaces do software com os demais elementos do sistema e especifique as restri es de projeto Ao engenheiro de software ou analista a an lise de requisitos permite uma aloca o mais precisa do software no sistema e a constru o de modelos do processo dos dados e dos aspectos comportamentais que ser o tratados pelo software Ao projetista esta etapa proporciona a obten o de uma representa o da informa o e das fun es que poder ser traduzida em projeto procedimental arquitet nico e de dados Al m disso poss vel definir os c
47. mais importante que a pr pria defini o de custos Numa vis o de desenvolvimento de software como produto um adicional nos custos de produ o pode ser absorvido por uma redefini o nos pre os ou pela amortiza o em fun o de um elevado n mero de vendas J um acr scimo imprevisto no prazo de entrega de um software pode provocar grandes preju zos ao produto como por exemplo a queda no impacto de mercado insatisfa o dos clientes eleva o de custos internos etc Quando a tarefa fixar prazos para os projetos de software diversas quest es podem ser formuladas como relacionar o tempo cronol gico com o esfor o humano que tarefas e que grau de paralelismo podem ser obtidos como medir o progresso do processo de desenvolvimento indicadores de progresso como o esfor o pode ser distribu do ao longo do processo de Engenharia de Software que m todos est o dispon veis para a determina o de prazos como representar fisicamente o cronograma e como acompanhar o progresso a partir do in cio do projeto As se es que seguem discutir o algumas destas quest es 3 1 As ReLa es Pessoas tRaBaLXO Em primeiro lugar preciso dizer que medida que um projeto ganha dimens o um maior n mero de pessoas deve estar envolvida Al m disso deve se tomar o cuidado de n o levar a s rio o mito apresentado no cap tulo de que Se o desenvolvimento do software estiver atrasado basta aumentar
48. menor a instala o de um sistema pode ser caracterizada pela ocorr ncia de muitos problemas que coloquem em risco o cumprimento de estimativas de prazo ou de custo Alguns problemas t picos desta etapa s o e O ambiente para o qual o sistema foi concebido n o precisamente o mesmo que foi especificado no in cio do projeto este um problema bastante comum em sistemas de software particularmente no que diz respeito utiliza o de certas facilidades do sistema operacional quando a vers o do sistema operacional do ambiente n o a mesma que foi utilizada para o desenvolvimento do sistema o resultado pode ser catastr fico e A resist ncia dos usu rios implanta o do novo sistema um outro problema importante nem sempre a ado o de um sistema computacional para a realiza o de uma tarefa que vinha sendo realizada de outra forma bem vista pelos funcion rios pois este vai na quase totalidade dos casos na necessidade de treinamento ou de altera o na sistem tica de trabalho um exemplo bastante bvio o da utiliza o de sistemas de software para a declara o de imposto de renda quando os primeiros programas foram lan ados muitas pessoas que tinham computadores ainda insistiam em utilizar os formul rios impressos para realizar suas declara es e A necessidade de coexist ncia entre um sistema antigo e o novo sistema outra fonte de problemas de instala o No caso dos sistemas compartilharem
49. o das estruturas de controle mais cl ssicas como sequ ncias condi es e repeti es A maior parte destas linguagens oferece um conjunto de estruturas sint ticas h CAP 7 LINGUAGENS DE PROGRAMA O PROF Vit rio BRUNO MAZZOLA quase que padronizadas que permitem exprimir estruturas como IF THEN ELSE DO WHILE REPEAT UNTIL e CASE Al m das estruturas cl ssicas mencionadas outros fatores podem ser interessantes como suporte a aspectos de programa o n o contemplados nestas estruturas Abaixo s o citados alguns destes fatores a recursividade que permite que um subprograma contenha em seu c digo uma ativa o a si pr prio a concorr ncia que permite a cria o de m ltiplas tarefas e oferece suporte comunica o e sincroniza o destas tarefas O tratamento de exce es que permite ativar a execu o de um conjunto de instru es a partir da ocorr ncia de um evento significativo do sistema computacional erro de execu o rel gio de tempo real etc ou definido pela aplica o interrup o causada pela press o de uma tecla chegada de uma mensagem etc 3 3 4 Suporte a abordagens orientadas a objeto N o obstante o resultado da aplica o de uma abordagem orientada a objeto possa ser codificada a partir de qualquer linguagem de programa o mapeamento dos elementos especificados no projeto fica mais simples se a linguagem de programa o oferece suporte a esta abordagem Send
50. opera o e a manuten o de software Afnor 83 Conjunto de m todos t cnicas e ferramentas necess rias produ o de software de qualidade para todas as etapas do ciclo de vida do produto Krakowiak 85 Num ponto de vista mais formal a Engenharia de Software pode ser definida como sendo a aplica o da ci ncia e da matem tica atrav s das quais os equipamentos computacionais s o colocados disposi o do homem por meio de programas procedimentos e documenta o associada De modo mais objetivo pode se dizer que a Engenharia de Software busca prover a tecnologia necess ria para produzir software de alta qualidade a um baixo custo Os dois fatores motivadores s o essencialmente a qualidade e o custo A qualidade de um produto de software um par metro cuja quantifica o n o trivial apesar dos esfor os desenvolvidos nesta dire o Por outro lado o fator custo pode o A CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF Vit rio BRUNO MAZZOLA ser facilmente quantificado desde que os procedimentos de contabilidade tenham sido corretamente efetuados 3 2 MopeLos ne DesenvoLvimento De sortware O resultado de um esfor o de desenvolvimento deve resultar normalmente num produto O processo de desenvolvimento corresponde ao conjunto de atividades e um ordenamento destas de modo a que o produto desejado seja obtido Um modelo de desenvolvimento corresponde a uma representa o abstrata d
51. os diferentes subsistemas indicam os fluxos de informa o que existem no sistema No caso de sistemas relativamente complexos comum que os subsistemas definidos neste primeiro n vel sejam por si s sistemas complexos Isto significa que para se ter uma id ia mais completa de como o sistema deve operar os subsistemas podem eventualmente ser representados utilizando a mesma linguagem Sistema de Sistema de Pais de Comunica o Sistema de ER omunica o Radar R dio da Aeronave Telefonia de Dados y Y Processador E Backup de Re Backup de de Posi o Posi o c EPS Comunica o omunica o Sistema de Base de Dados Simula o da de V o Aeronave li Sistema de Mapa gt Meteorol gico Sistema de 4 SOE Terminais de Contagem Controle do Controle Sistema de Registrode lt Atividades Figura 3 4 Exemplo de projeto arquitetural um sistema de controle de tr fego a reo Num sistema computacional os diagramas de arquitetura destacam na forma de subsistemas os elementos que dever o ser
52. para a constru o de um novo produto mais competitivo e eficiente o que define uma forma de reusabilidade de software as especifica es formais e os ambientes de prototipa o que surgiram em substitui o s t cnicas baseadas em linguagem natural as vantagens da utiliza o destas t cnicas s o basicamente a representa o dos requisitos de software numa linguagem padr o a gera o de c digo execut vel a partir da especifica o e a possibilidade de valida o da parte do cliente de modo a refinar os requisitos do software 6 ESPECIFICA O DOS REQUISITOS DE SOFTWARE Como foi exposto no in cio do cap tulo item 2 4 a etapa de An lise de Requisitos culmina com a produ o de um documento de Especifica o dos Requisitos de Software Este resultado pode vir na forma de um documento em papel utilizando linguagem natural ou gr fica pode ter sido produzida com o aux lio de uma ferramenta CASE ou ainda pode ser complementada ou expressa a partir de um prot tipo constru do nesta etapa Este documento basicamente o resultado de um trabalho de representa o das necessidades para a solu o do problema analisado devendo expressar os aspectos funcionais informacionais e comportamentais do software a ser constru do De modo a obter uma especifica o eficiente alguns princ pios podem ser considerados a separa o entre funcionalidade e implementa o utiliza o de uma linguagem de especifica
53. poss veis rela es entre estas Aeronave Decolagem Passageiro E Aterrissagem Plano de V o Figura 5 8 Exemplo de Diagrama Entidade Rela o BA CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA 8 t cnicas De AN LISE 8 1 t cnicas ORIentanas Estado Apesar de apresentarem aspectos interessantes no que diz respeito ao desenvolvimento da tarefa de An lise de Requisitos as ferramentas da t cnica de An lise Estruturada de Sistemas n o permitem cobrir todos os aspectos importantes de determinadas classes de sistemas Um exemplo disto s o os sistemas reativos e de tempo real onde a ordena o de eventos e os aspectos de temporiza o podem assumir uma import ncia fundamental no entendimento do problema a ser resolvido Por esta raz o nestes casos sem d vida mais interessante realizar a formaliza o do problema utilizando uma t cnica baseada no conceito de estados Os par grafos a seguir apresentar o algumas das t cnicas orientadas a estados que s o teis na etapa de An lise de Requisitos 8 1 1 As Tabelas de Decis o As tabelas de decis o s o utilizadas para expressar decis es l gicas de alta complexidade Estas s o caracterizadas por quatro quadrantes o quadrante de condi es o quadrante de a es as entradas de condi es e as entradas de a es O quadrante de condi es cont m todas as condi es que ser o examinadas na an lise de um pro
54. processo de desenvolvimento uma tarefa bastante complexa principalmente porque entram muitas vezes em jogo um conjunto de informa es conflitantes Ainda quanto mais complexo o sistema a ser desenvolvido mais inconsist ncia haver com rela o s informa es obtidas Neste contexto o analista deve ter bom senso e experi ncia para extrair de todo o processo de comunica o as boas informa es Y PRINC PIOS De AN LISE Independente do m todo utilizado para realizar a an lise de requisitos existem algumas preocupa es que s o comuns a todos eles os quais discutiremos nos par grafos que seguem 1 O Dom nio De Inrorma o Todo software constru do com a fun o b sica de processar dados n o importa a rea de atua o considerada Como j discutimos no cap tulo anterior poss vel representar um software na sua concep o mais cl ssica como um sistema que recebe um conjunto de informa es ou dados de entrada realiza o tratamento ou processamento desta informa o e produz informa es de sa da Al m dos dados um software capaz de processar eventos onde cada evento est relacionado a um aspecto de controle do sistema como por exemplo um sensor que capaz de detectar a ultrapassagem de um determinado limite de press o ou temperatura pode gerar um evento um sinal de alarme para que o software de monitora o alerte o operador ou efetue alguma a o previamente definida Ist
55. que continha todas as rotinas de programa o e acesso aos dispositivos de hardware que compunham a arquitetura do PC S a partir do momento em que as outras empresas conseguiram copiar o conte do do ROM BIOS que surgiram os conhecidos clones do PC que difundiram a tecnologia pelo mundo todo Usu rio do Sistema Principal Contratante Subcontratante 1 Subcontratante 2 Subcontratante 2 Figura 3 2 Ilustra o do processo de aquisi o de um sistema 3 6 CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS O papel essencial da Engenharia de Sistemas Computacionais a resolu o de problemas onde a atividade de base a identifica o an lise e atribui o aos elementos constituintes do sistema das fun es desejadas para o sistema A palavra que melhor define a Engenharia de Sistemas a interdisciplinaridade uma vez que na maior parte dos sistemas a serem concebidos devem entrar em jogo diferentes compet ncias Al m dos Engenheiros de Hardware e de Software devem intervir nesta etapa especialistas como Engenheiros Eletricistas Engenheiros Hidr ulicos Engenheiros de Telecomunica es Qu micos F sicos Psic logos M dicos etc O ponto de partida do trabalho do Engenheiro de Sistemas s o os requisitos e restri es formuladas pelo cliente que v o permitir um primeiro delineamento das fun
56. que os nomes de associa o s o em it lico As associa es podem ser bin rias ter rias ou de ordem maior De fato a maior parte bin ria ou qualificada i e uma forma especial de ter ria que ser comentado a seguir A simbologia OMT para ter ria ou n rio um losango com linhas conectando este as classes relacionadas O nome da associa o escrito dentre do losango entretanto os nomes de associa o s o opcionais A figura 9 6 mostra exemplos de associa es e liga es ter rias A multiplicidade especifica quantas inst ncias de uma classe podem se relacionar a uma nica inst ncia de classe associada A multiplicidade restringe o n mero de objetos relacionados A multiplicidade depende de hip teses e de como se define os limites do problema Requisitos vagos tornam a multiplicidade incerta N o poss vel de determinar muito cedo a multiplicidade no processo de desenvolvimento de software num primeiro tempo determina se objetos classes liga es e associa es e depois decide se a respeito de multiplicidade A distin o mais importante entre um e v rios entretanto existem s mbolos especiais para exatamente um um ou mais intervalos zero ou mais zero ou um conforme mostra a figura 9 7 E pas tem por capital Cidade Diagrama DO E ralo tem por capital Cidade Fran a Paris RR Pa s enporti Cidade Diag
57. realizado modifica es podem ser introduzidas Uma vantagem desta abordagem a facilidade em testar o sistema uma vez que a realiza o de testes em cada n vel de desenvolvimento sem d vida mais f cil do que testar o sistema final Al m disso como na Prototipa o a obten o de um sistema mesmo incompleto num dado n vel pode oferecer ao cliente interessantes informa es que sirvam de subs dio para a melhor defini o de futuros requisitos do sistema No primeiro passo deste modelo uma implementa o inicial do sistema obtida na forma de um subconjunto da solu o do problema global Este primeiro n vel de sistema deve contemplar os principais aspectos que sejam facilmente identific veis no que diz respeito ao problema a ser resolvido Um aspecto importante deste modelo a cria o de uma lista de controle de projeto a qual deve apresentar todos os passos a serem realizados para a obten o do sistema final Ela vai servir tamb m para se medir num dado n vel o qu o distante se est da ltima itera o Cada itera o do modelo de Desenvolvimento lIterativo consiste em retirar um passo da lista de controle de projeto atrav s da realiza o de tr s etapas o projeto a implementa o e a an lise O processo avan a sendo que a cada etapa de avalia o um passo retirado da lista at que a lista esteja completamente vazia A lista de controle de projeto gerencia todo o desenvolvimento definindo qu
58. realizar as fun es do software Aspectos como a arquitetura do software as estruturas de dados os procedimentos a serem implementados a forma como o projeto ser transformado em linguagem de programa o a gera o de c digo e os procedimentos de teste devem ser encaminhados nesta fase Normalmente esta fase tamb m organizada em tr s principais etapas e o Projeto de Software o qual traduz num conjunto de representa es gr ficas tabulares ou textuais os requisitos do software definidos na fase anterior estas representa es diversas t cnicas de representa o podem ser adotadas num mesmo projeto permitir o definir com um alto grau de abstra o aspectos do software como a arquitetura os dados l gicas de comportamento algoritmos e caracter sticas da interface e a Codifica o onde as representa es realizadas na etapa de projeto ser o mapeadas numa ou em v rias linguagens de programa o a qual ser caracterizada por um conjunto de instru es execut veis no computador nesta etapa considera se tamb m a gera o de c digo de implementa o aquele obtido a partir do uso de ferramentas compiladores linkers etc e que ser executado pelo hardware do sistema Lje CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF Vit rio BRUNO MAZZOLA e os Testes de Software onde o programa obtido ser submetido a uma bateria de testes para verificar e corrigir defeitos relativos s fu
59. referenciar rela o entre classes enquanto a heran a diz respeito ao mecanismo de compartilhar atributos e opera es usando a rela o de generaliza o Generaliza o e especializa o s o dois pontos de vista da mesma rela o no primeiro caso vista a partir da superclasse e no segundo da subclasse a superclasse generaliza a subclasse e a subclasse refina ou especializa a superclasse 4 1 6 M dulo Um m dulo uma constru o l gica para reagrupar classes associa es e generaliza es Um m dulo captura uma perspectiva ou uma vista de uma situa o como no caso de um pr dio existem v rias vis es correspondentes a planta el trica hidr ulica de calefa o Um modelo objeto consiste de um ou v rios m dulos A no o de m dulo for a a particionar um modelo objeto em pe as gerenciaveis Uma mesma classe pode ser referenciada em m dulos diferentes De fato referenciando a mesma classe em m ltiplos m dulos o mecanismo para interligar m dulos entre s Documento af Paragrato Figura 9 11 Agrega o gig CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA Figura cor posi o centro largura pena tipo pena mover selecionar rodar mostrar dimensionalidade 0 Dimensional 1 Dimensional 2 Dimensional E a orienta o orienta o preenchimento redimensionar preencher ren redimensionar
60. se vai evoluindo na an lise novos processos de transforma o v o sendo acrescentados nos DFDs de n veis inferiores correspondendo aos detalhamentos realizados em processos de um dado n vel A figura 5 6 ilustra esta situa o Um exemplo de DFD resultante da an lise de um sistema de folha de pagamento apresentado na figura 5 7 Quando m ltiplos dados s o necess rios por um processo um asterisco introduzido junto aos diferentes fluxos de dados representando um relacionamento E Um relacionamento do tipo OU pode tamb m ser definido se necess rio pela introdu o de um sinal de adi o entre os fluxos de dados Figura 5 6 Refinamento de um DFD arquivo empregado arquivos da companhia pre o hora extra Obt m Arquivo Pagamento al a e Empregado Mensal ora Extra escontos sal rio parcial l quido pre o hora horas m s cheque matr c empregado horas extras taxas de descntos Trabalhador Trabalhador Figura 5 7 DFD de um sistema de folha de pagamento a i CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA importante ressaltar que o DFD da figura 5 7 corresponde a um sistema de folha de pagamento independente da forma como este implementado manual ou autom tico o que sugere o caracter de abstra o deste m todo Nesta primeira vis o do sistema exemplo detalhe
61. sistema projeto de objetos e implementa o Como principais caracter sticas destacam se a separa o clara entre an lise e projeto a inclus o de todos os conceitos da orienta o a objetos e de alguns espec ficos do m todo A fase de an lise baseada de 3 diagramas relacionados entre si e que representam os modelos de objetos din mico e funcional 3 2 T cnica De Boocx A t cnica Booch dividida em 3 fases an lise de requisitos an lise de dom nios e projeto com nfase maior no projeto Os diagramas seguintes s o providos de classes de transi o de estados de objetos temporais de m dulos e de processos 3 3 T cnica ne Coan YourDon Esta t cnica utiliza um modelo nico para todas as fases OOA OOD e OOP o que torna mais simples e compreens vel o desenvolvimento 3 4 t cnica ve SwLaer IMeLLoR Ela fornece um conjunto integrado de modelos de an lise e que depois s o traduzidos Recursive Design durante o projeto 3 5 t cnica 00S Jacosson A t cnica OOSE centrada em casos de uso use cases e permite durante a an lise aprofundar o entendimento de como o sistema deve ser realmente utilizado 3 6 T cnica Fus o A Fus o corresponde a uma integra o das t cnicas OMT e de Booch na qual os dois modelos de objeto e de interface visam representar os aspectos est ticos e din micos do problema 9 4 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOL
62. sistema desempenho seguran a disponibilidade s o alguns exemplos desta categoria de requisitos e as caracter sticas indesej veis que s o propriedades que o sistema n o deve possuir t o importante muitas vezes definir que caracter sticas n o devem ser encontradas num dado sistema quanto definir aquelas que s o consideradas essenciais num sistema de comunica o de dados por exemplo algumas caracter sticas indesej veis s o os erros as perdas e as duplica es de mensagens De forma geral importante que sejam estabelecidos da forma mais completa poss vel os objetivos e as fun es a serem providas pelo sistema Neste n vel deve se enfatizar o papel do sistema computacional no ambiente em que ele ser instalado podendo se deixar para etapas mais frente a especifica o dos aspectos funcionais do mesmo Observemos a distin o atrav s de um exemplo onde s o apresentadas duas vers es de especifica o dos requisitos de um sistema de seguran a para um edif cio comercial a O objetivo do sistema prover um sistema de prote o contra inc ndio e intrus o que vai ativar um alarme interno e externo em caso de princ pio de inc ndio ou invas o por pessoas n o autorizadas z b O objetivo do sistema assegurar a continuidade do funcionamento normal conduzido no edif cio mesmo na ocorr ncia de eventos como o princ pio de inc ndio ou intrus o Neste n vel do desenvolvimento do s
63. ssicos que funcionam como blocos de constru o building blocks de estruturas mais complexas A figura 6 2 ilustra alguns destes construtores Os construtores ilustrados podem ser combinados das mais diversas maneiras para obter estruturas de dados com grau de complexidade relativamente complexo 3 7 Procenimentos De Sortware Os procedimentos de software t m por objetivo expressar em detalhes a opera o de cada componente de software m dulo individualmente Os aspectos a serem expressos nos procedimentos de software s o o processamento da informa o o seq enciamento de eventos os pontos de decis o as opera es repetitivas e eventualmente se houver necessidade algumas estruturas de dados 6 5 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA E mao E E E E item escalar vetor lista e espa o n dimensional rvore Figura 6 2 Alguns construtores cl ssicos de estruturas de dados evidente que a constru o de procedimentos de software uma atividade que deve ser feita tendo como refer ncia a hierarquia de controle Isto porque na defini o do procedimento de um dado m dulo de software deve ser feita refer ncia a todos os m dulos subordinados a ele Normalmente esta refer ncia ser desenvolvida num n vel mais baixo de detalhamento de modo a se obter o procedimento de software do m dulo subordinado 3 8 Ocuta o De Inrorma o O princ pio da oculta o de infor
64. teste anteriores de unidade e de integra o apresenta as propriedades e a funcionalidade definidas na etapa de especifica o dos requisitos Pode se dizer que um teste de valida o bem sucedido aquele que d um m ximo de respostas sobre a capacidade do software apresentar ou n o um funcionamento o mais pr ximo poss vel daquele esperado pelo cliente ou usu rio O problema como medir esta proximidade Nesta medida um conjunto de informa es importantes s o aquelas definidas no documento de especifica o de requisitos Esta uma das raz es pelas quais importante que se busque na fase de especifica o dos requisitos utilizar par metros mensur veis para definir os requisitos do software rever o cap tulo 5 6 1 O PROCESSO DE teste De VALIDA O O teste de valida o realizado atrav s de um conjunto de testes de caixa preta cujo objetivo determinar a conformidade do software com os requisitos definidos nas fases preliminares da concep o Um documento de plano de testes eventualmente definido na etapa de An lise de Requisitos define quantos e quais testes ser o realizados Os requisitos s o analizados sob v rios pontos de vista funcionais desempenho documenta o interface e outros requisitos portabilidade compatibilidade remo o de erros etc O resultado do teste de valida o pode apresentar um dos dois resultados 1 as caracter sticas de fun o desempenho e outros asp
65. tipos embutidos nos compiladores ou interpretadores O objetivo deste mecanismo garantir a coer ncia dos programas com rela o s estruturas de dados e s opera es que podem ser realizadas sobre eles 3 3 2 Os subprogramas Os subprogramas correspondem a componentes de programa contendo estruturas de controle e dados que podem ser compilados separadamente Com rela o aos elementos de um software definidos na etapa de projeto pode se eventualmente considerar subprogramas como o mapeamento natural dos m dulos de um software embora n o necessariamente os m dulos que correspondem a uma defini o mais gen rica ser o mapeados em subprogramas Os subprogramas recebem diferentes denomina es dependendo da linguagem de programa o considerada subrotinas procedimentos fun es m dulos agentes processos objetos Independentemente da linguagem de programa o considerada os subprogramas s o caracterizados pelos seguintes elementos uma se o de especifica o declara o contendo o seu identificador e uma descri o da interface uma se o de implementa o onde descrito o seu comportamento atrav s das estruturas de controle e dados um mecanismo de ativa o o qual permite invocar o subprograma a partir de um ponto qualquer do programa por exemplo uma instru o call 3 3 3 Estruturas de controle Praticamente todas as linguagens de programa o oferecem suporte representa
66. 2 Fun es principais 1 3 Desempenho 1 4 Restri es T cnicas e Administrativas 2 0 Estimativas 2 1 Dados utilizados 2 2 T cnicas de Estimativa 2 3 Estimativas 3 0 Riscos do Projeto 3 1 An lise dos Riscos 3 2 Administra o dos Riscos 4 0 Cronograma 4 1 Divis o do esfor o no projeto 4 2 Rede de Tarefas 4 3 Timeline 4 4 Tabela de recursos 5 0 Recursos necess rios 5 1 Pessoal 5 2 Software e Hardware 5 3 Outros recursos 6 0 Organiza o do Pessoal 7 0 Mecanismos de Acompanhamento 8 0 Ap ndices Figura 4 7 Proposta de estrutura para o documento de Plano do Software O Plano de Software n o necessita ser um documento extenso e complexo O seu objetivo auxilar a an lise de viabilidade dos esfor os de desenvolvimento Este documento est associado aos conceitos de o que quanto e qu o longo associados ao desenvolvimento As etapas mais frente v o estar associadas ao conceito de como 4 15 Engenharia de Software CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA Car tuLo 5 An LISe De Reguisros 1 INTRODU O O completo entendimento dos requisitos de software um ponto fundamental para o sucesso de um projeto de software Independente da precis o com a qual um software venha a ser projetado e implementado ele certamente trar problemas ao cliente usu rio se a sua an lise de requisitos foi mal realizada A An
67. A 3 6 t cnica UML UML ou Unified Modeling Language uma unifica o dos m todos OMT Booch e OOSE que est sendo submetido a OMG para a padroniza o A t cnica OMT ser descrita mais detalhadamente nos itens seguintes y MODELAGEM ORIENTADA A OBJETOS Um modelo uma abstra o que tem como prop sito entender um problema antes de solucion lo A partir de modelos poss vel simular e testar sistemas antes de constru los facilitar a comunica o com os usu rios e os outros membros da equipe de desenvolvimento visualizar e reduzir a complexidade dos problemas a tratar No modelo OMT temos 3 vis es combinadas que permitem representar o sistema e um modelo objeto para representar os aspectos est ticos estruturais de dados de um sistema e um modelo din mico para representar os aspectos temporal comportamental e de controle de um sistema e um modelo funcional para representar os aspectos transformacionais e de fun o de um sistema Esses modelos n o s o independentes existem interconex es limitadas e expl citas LI O monelo oBJero O modelo objeto descreve a estrutura de objetos no sistema sua identidade suas rela es com os outros objetos seus atributos e suas opera es Este modelo tenta capturar a estrutura est tica dos componentes do mundo real que pretende se representar O modelo objeto tem uma representa o gr fica na forma de diagramas contendo as classes de obj
68. Capacidade de Define pr condi es necess rias no projeto ou organiza o Atividades Descreve os procedimentos necess rios para implementar realizadas uma rea chave Medidas e Indica a necessidade de realiza o de atividades de medi o an lises e an lise das medidas Verifica o da Corresponde aos passos necess rios para assegurar que implementa o todas as tarefas foram realizadas adequadamente Tabela 2 2 Fatores comuns Embora os dois objetivos sejam diferentes definido no modelo um procedimento similar para a realiza o dos dois tipos de an lise As etapas deste procedimento descritas a seguir dever o ser realizadas num esquema sequencial e sele o de uma equipe cujos elementos ser o treinados segundo os conceitos b sicos do modelo CMM sendo que estes j dever o ter conhecimentos de engenharia de software e gerenciamento de projetos e selecionar profissionais representantes da organiza o para os quais ser aplicado um question rio de maturidade e analisar as respostas obtidas do question rio de maturidade procurando identificar as reas chave CAP 2 QUALIDADE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA N vel 2 Repet vel P N indica cont m Di Processo Planejamento disciplinado do Projeto na cam ii F AS atinge organizado por GE ES ER Estima o para utiliza o Atividades no planejamento e Realizadas acompanhamento do o F ES A
69. Engenharia de Software SUM RIO Car tuLo 1 EnGenxaRIA De SortwaRe Concerros B SICOS Te AM OON O en en a aonde nando Seade gana o a df a SER aa 1 1 2 Principais Aspectos do Software rear aaaana 1 2 3 Paradigmas da Engenharia de Software 1 5 4 Vis o geral da Engenharia de Software a 1 11 CartuLo 2 QUALIDADE DE SOFTWARE Te AOCU O seenen rates east adore en ana teta an EEE ig o Abadia 2 1 2 Defini o de Software de Qualidade san 2 1 3 Metrologia da Qualidade de Software rias 2 4 4 Quest es Importantes Qualidade de Software esseere 2 4 Se OrModelo CMM sas gnt OS a EST 2 6 CartuLo 3 PLANEJAMENTO DO DesenvoLvImento De SortwARe U tro 6 Ue 1e MPR O DR RR RD RR RC ETTE UR URSO 3 1 2 Analise de RISCOS setar caos ira ltna da Sosa tra aaa o E aaa ads aE E a EEEE 3 1 3 Defini o de um Cronograma ses sasisasoserads santas dunietisasCEadsa ata assess grande 3 4 4 Aquisi o de SONWARS en saia Sd Desen O RAR NO Re Rana a da ERA NO ROSES RAND 3 8 57 ReCNGENhANA as sat isa ds Ia a air apenso 3 9 6 Planejamento Organizacional sapeasasssioprgranagaesssna e GosMad acho nisc nega ana due passada Epa 3 9 7 O Plano de Software aaaisa sms ias oral uniao pras anal sua ng a P aNSna SR Ene Fina une 3 10 Car tuo Y EnGenxARIA De Sistemas COMPUACIONAIS Ts ANIPOdU O enere Lada ESSES SOS Donna sia anda
70. LOC Custo 8 KLOC Documenta o p gs KLOC A despeito da facilidade em sua obten o existe muita discuss o em torno das m tricas orientadas ao tamanho Um caso bastante discutido o da utiliza o do n mero de linhas de c digo como medida de dimens o Os que defendem o uso desta m trica afirmam que um aspecto de f cil obten o e portanto de f cil aplica o a qualquer projeto de software al m de destacar a quantidade de informa o existente com base nesta m trica Projeto Fsiotco Gusto KLOC P go Eros Pessoas AMO 24 168 Ceci Pa Do Os que discutem o uso desta informa o alertam para a forte depend ncia da linguagem no uso desta t cnica Al m disso a m trica orientada ao tamanho tende a penalizar os programas bem estruturados e que tenham feito economia de software E uma m trica que na verdade deixa de ser precisa principalmente por causa dos diversos novos fatores introduzidos pelas linguagens de programa o mais recentes al m de ser de dif cil aplica o para efeito de estimativas uma vez que necess rio descer a um n vel de detalhe que n o desej vel na etapa de planejamento do projeto TM M tricas orientanas run o Esta classe baseada em medidas indiretas do software e do processo utilizado para obt lo Em lugar da contagem do n mero de linhas de c digo esta m trica leva em conta aspectos como a funcionalidade e a utilidade do programa Uma ab
71. N Autorize empr stimo Rejeite empr stimo X Figura 5 10 Uma tabela de decis es com entradas limitadas Caso duas ou mais regras id nticas conduzam s mesmas a es elas s o consideradas redundantes Caso elas conduzam a a es diferentes elas s o consideradas contradit rias Regras contradit rias n o s o necessariamente indesej veis Elas podem ser utilizadas para expressar o n o determinismo de um dado problema Uma tabela de decis es considerada completa se todas as poss veis combina es de condi es podem ser associadas a uma a o Numa tabela com N entradas de condi o v o existir 2N poss veis combina es A n o especifica o de uma ou mais combina es vai resultar numa tabela de decis es incompleta 8 1 2 As tabelas de transi o As tabelas de transi o s o utilizadas para especificar mudan as no estado de um sistema como resultado da a o de eventos caracter sticos O estado de um sistema caracteriza as condi es de todas as entidades do sistema num dado instante Para um estado S a ocorr ncia de uma condi o C vai provocar a passagem ou transi o ao estado Sp Um exemplo de tabela de transi o apresentada na figura 5 11 que representa um sistema composta de dois estados S S1 nos quais duas entradas a e b podem ocorrer Como se pode notar na figura as entradas rotuladas por a fazem com que o sistema permane a no seu estado atual S ou S1 As entradas rotuladas po
72. OF VIT RIO BRUNO MAZZOLA Dentro deste princ pio os cuidados a serem tomados dever o ser o desenvolvimento de programas com bom n vel de legibilidade e a estrutura o em componentes de software facilmente modific veis agrupar altera es vis veis ao usu rio e eventuais corre es em vers es numeradas manter a documenta o atualizada IM O PRINC PIO Da MIGRA O O sortwaRe ser MStaLaDo em outras m gumas Este ltimo princ pio leva em conta o fato de que a vida de muitos softwares deve ultrapassar a vida da pr pria m quina em que ele est executando A velocidade com a qual as arquiteturas de computador t m evoluido nos ltimos anos acentua a import ncia deste princ pio Um problema relacionado a este princ pio que s vezes os programas s o desenvolvidos explorando algumas particularidades das arquiteturas das m quinas para as quais eles est o sendo concebidos Isto cria uma forte depend ncia do hardware o que dificulta a futura migra o para outras arquiteturas Isto significa na verdade que para um programa apresentar um n vel satisfat rio de portabilidade o programador deve evitar amarrar se a detalhes de hardware da m quina ao inv s de aproveit los Assim podemos sintetizar as a es a serem preparadas com rela o a este princ pio pensar os programas como meio para solucionar problemas e n o para instruir determinado processador e utilizar as constru es pa
73. TOS DA ENGENHARIA DE SISTEMAS COMPUTACIONAIS 2 Sistema ComputacionaL Antes de discutir os principais pontos relativos Engenharia de Sistemas Computacionais imprescind vel estabelecer uma defini o do que um sistema computacional Isto particularmente importante uma vez que a palavra sistema uma das mais empregadas em qualquer rea da atividade humana sistema pol tico sistema educacional sistema de avalia o etc 3 2 CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA Dentro do contexto do que ser discutido aqui pode se definir um Sistema Computacional como sendo um conjunto de elementos interrelacionados que operam juntos para o alcance de algum objetivo Um sistema de processamento de texto por exemplo integra fun es de entrada e edi o de texto com fun es de produ o de documentos software e hardware manipuladas por um usu rio um elemento humano para transformar um dado texto uma entrada num documento a sa da Pode se listar os elementos de um sistema computacional como sendo software no caso programas de computador estruturas de dados e documenta o associada que serve a efetivar os m todos procedimentos ou processo de controle l gico hardware que s o os dispositivos eletr nicos que definem as capacidades de um computador e dispositivos eletromec nicos que oferecem funcionalidades ao ambiente externo pessoal usu r
74. a ao n mero de n veis de abstra o definidos para a representa o do software e a largura que permite concluir sobre a abrang ncia do controle global do software pa CAP 6 PROJETO DE SOFTWARE PROF Vit rio BRUNO MAZZOLA fan out m Figura 6 1 Representa o da hierarquia de controle o fan out que permite definir a quantidade de m dulos controlados por um dado m dulo O fan in que indica quantos m dulos controlam um dado m dulo Ainda poss vel estabelecer as rela es de controle entre os m dulos Um m dulo que exerce controle sobre outros m dulos denominado o m dulo superordenado Um m dulo que controlado por outro dito um m dulo subordinado a ele 3 6 A Estrutura Dos Dados A estrutura dos dados representa os relacionamentos l gicos entre os diferentes elementos de dados individuais A medida que o projeto se aproxima da implementa o esta representa o assume fundamental import ncia j que a estrutura da informa o vai exercer um impacto significativo no projeto procedimental final A estrutura dos dados define a forma como est o organizados os m todos de acesso o grau de associatividade e as alternativas de processamento das informa es Apesar de que a forma de organizar os elementos de dados e a complexidade de cada estrutura dependam do tipo de aplica o a desenvolver e da criatividade do projetista existe um n mero limitado de componentes cl
75. a de generaliza o rela o do tipo or sobre os estados Os estados num diagrama aninhado s o todos refinamentos sub estados de um estado super estado de um diagrama de alto n vel a simbologia utilizada corresponde a uma caixa arredondada representando o super estado e contendo todos seus sub estados Eventos podem tamb m ser expandidos em diagramas de estados subordinados Os eventos podem ser organizados numa hierarquia de generaliza o com heran a dos atributos de eventos A hierarquia de eventos permite que diferentes n veis de abstra o sejam usados em diferentes lugares num modelo 4 2 4 Concorr ncia Um modelo din mico descreve um conjunto de objetos concorrentes cada um com seu pr prio diagrama de estados Os objetos num sistema s o inerentemente concorrentes e podem mudar de estados de forma independente O estado do sistema total o resultado dos estados de todos os seus objetos Um diagrama de estados no caso da jun o assembly de objetos atrav s de agrega o rela o and uma cole o de diagrama de estados concorrentes um para cada componente Entretanto em v rios casos os estados dos componentes interagem transi es guardadas para um objeto podem depender do estado de um outro objeto A concorr ncia pode tamb m ocorrer dentro do estado de um nico objeto quando o objeto pode ser particionado em subconjuntos de atributos ou liga es cada um com seu pr prio sub diagr
76. a equipe para honrar o prazo de desenvolvimento Deve se considerar ainda que quanto maior o n mero de pessoas maior o n mero de canais de comunica o o que normalmente requer esfor o adicional e consequentemente tempo adicional A experi ncia tem mostrado que pode ser mais interessante realizar o desenvolvimento de um software com uma equipe com menos pessoas por um per odo maior de tempo quando as restri es de prazo de entrega assim o permitem do que o contr rio 3 2 R Dermi o De Vareras Uma das vantagens de se ter uma equipe com mais de uma pessoa s o as possibilidades de se realizar determinadas tarefas em paralelo O paralelismo de tarefas um mecanismo interessante como forma de economia de tempo na realiza o de qualquer trabalho de engenharia Para isto basta que um gerenciamento dos recursos necess rios a cada tarefa recursos humanos recursos de software etc seja feito de forma eficiente Sendo assim as tarefas a serem realizadas durante um projeto de desenvolvimento de software podem ser expressas na forma de uma rede rede de tarefas a qual apresenta todas as tarefas do projeto assim como as suas rela es em termos de realiza o paralelismo sequ ncia pontos de encontro etc Um exemplo desta representa o apresentado na figura 4 3 Nesta figura poss vel verificar que existem indicadores de progresso representados por um s mbolo situados ao longo do processo e que permi
77. a para que se possa derivar um projeto contendo as caracter sticas citadas acima As se es que seguem discutir o alguns destes conceitos 31 Restra o O princ pio de abstra o est fortemente relacionado com as caracter sticas de modularidade que um software pode apresentar Quando se desenvolve um software que vai apresentar estas caracter sticas comum que suas representa es sejam feitas considerando v rios n veis de abstra o No que diz respeito linguagem de representa o nos n veis mais altos de abstra o a linguagem utilizada bastante orientada aplica o e ao ambiente onde o software ir ser executado A medida que se vai descendo nos n veis de abstra o a linguagem de representa o vai se aproximando de quest es de implementa o at que no n vel mais baixo a solu o representada de modo a que possa ser derivada diretamente para uma linguagem de implementa o Na realidade o pr prio processo de Engenharia de Software constitui se num aprimoramento de n veis de abstra o Na Engenharia de Sistemas por exemplo parte das tarefas do sistema a desenvolver s o atribu das ao software como elemento constituinte de um sistema computacional Na An lise de Requisitos a solu o em termos de software apresentada de forma conceitual Durante o Projeto partindo do Projeto Preliminar para o Projeto Detalhado m ltiplos n veis de abstra o v o sendo definidos aproximando se
78. a pela previsibilidade uma vez que os processos s o medidos e operam em limites conhecidos 5 2 5 N vel OumizaDo No n vel otimizado a organiza o promove cont nuos aperfei oamentos no processo de desenvolvimento utilizando para isto uma realimenta o quantitativa do processo e aplicando novas id ias e tecnologias Os aperfei oamentos s o definidos a partir da identifica o dos pontos fracos e imperfei es do processo corrente e do estabelecimento das altera es necess rias para evitar a ocorr ncia de falhas An lises de custo benef cio s o efetuadas sobre o processo de desenvolvimento com base em dados extra dos de experi ncias passadas Quando os problemas relacionados ado o de um dado processo de desenvolvimento n o podem ser totalmente eliminados os projetos s o cuidadosamente acompanhados para evitar a ocorr ncia de problemas inerentes do processo 5 3 Dermi o operacional Do monero CMM O modelo CMM al m de definir os n veis de maturidade acima descritos detalha cada um deles com respeito aos objetivos essenciais de cada um e das tarefas chave a serem implementadas para que estes objetivos sejam atingidos Para isto foi realizado exce o do n vel 1 um detalhamento nos diferentes n veis estabelecendo uma estrutura que permitisse caracterizar a maturidade e a capabilidade do processo de desenvolvimento de software A figura 2 2 ilustra os componentes relacionados a este detalhamento
79. ace 6 2 1 Os diferentes modelos utilizados no projeto Dado que as interfaces homem m quina v o envolver diferentes elementos do sistema computacional pelo menos o software e pessoas o projetista deve manipular diferentes modelos para obter um resultado em termos de interface que seja compat vel com os fatores t cnicos e humanos desejados Um primeiro modelo a ser definido e utilizado pelo projetista o modelo de projeto que est relacionado representa o de todos os as pectos do software procedimentos arquitetura dados etc Um outro modelo a ser desenvolvido pelo projetista um modelo de usu rio o qual permite descrever o perfil t pico do usu rio do software Par metros como idade sexo forma o motiva o capacidades f sicas personali dade etc s o levados em conta na constru o deste modelo Al m destas caracter stica s o grau de experi ncia e de utiliza o de um software pode intervir o que permite classificar os usu rios em principiantes instru dos e intermitentes e instru dos e freq entes A localiza o nesta classifica o corresponde ao grau de conhecimento sem ntico o co nhecimento das fun es b sicas relativas aplica o e conhecimento sint tico a forma de intera o com o software apresentado pelo usu rio A percep o do sistema corresponde a um modelo estabelecido pelo usu rioque representa a sua vis o do que ser o software Nest modelo o usu rio descreve
80. ace homem m quina consiste invariavelmente num processo iterativo onde um modelo de projeto criado implementado na forma de prot tipo e vai sendo refinado e aproximando se da vers o definitiva medida que recebe realimenta es por parte de usu rios t picos do software Um aspecto importante neste processo a disponibilidade de ferramentas de suporte abordagem que permitam obter com certa agilidade os modelos de projeto e realizar as modifica es necess rias de modo a obter as vers es finais Atualmente existem diversos conjuntos de ferramentas de suporte ao desenvolvimento de interfaces as quais oferecem bibliotecas para a constru o dos elementos b sicos como janelas menus caixas de di logos mensagens de erros etc Alguns ambientes de programa o mais recentes incluem a possibilidade do programador desenhar o aspecto visual das telas da interface e obter automaticamente o c digo dos m dulos de interface a partir dos desenhos Uma vantagem do uso de tais ferramentas al m da redu o do esfor o de desenvolvimento a obten o de uma interface que respeite a determinados padr es de apar ncia e acesso a comandos j adotados por outras aplica es de uma mesma plataforma 6 15 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 6 3 Princ Pios DO Projeto De Interfaces De modo a cumprir o objetivo de gerar uma interface que permita ao usu rio explorar completa e eficientement
81. ada dispara quando o evento ocorre e que a condi o de guarda verdadeira chamador levanta o fone Chamador Linha Telef nica Correspondente inicia tom de discagem i chamador pressiona d gito 5 p ra o tom de discagem chamador pressiona d gito 5 chamador pressiona d gito 5 chamador pressiona d gito 1 2 3 chamador levanta o foney E in cio tom de discagem _ 4 r 7 f pressiona d gito 5 fim tom de discagem __ pressiona d gito 5 pressiona d gito 5 So chamador pressiona d gito f a ressiona d gito 1 i chamador pressiona d gito RE d gito gt e chamador pressiona d gito 4 pressiona d gito 3 gt telefone chamado come a a tocar i pressiona d gito 4 aeo omde chamada campainha Helene i atendimento telefone __ telefone chamado p ra de tocar parada tom de chamada E parada campainha ie di asa telefone do chamador telefones conectados telefones conectados eletones est o conectados Correspondente desliga _ correspondente rep e o fone no gancho D conex o desfeita conex o desfeita telefones est o desconectados chamador desliga i chamador p e fone no gancho f Figura 9 13 Cen rio e tra o de eventos para uma chamada telef nica 9 12 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA fone no gancho fone no gancho Ocioso
82. ados Em fun o das respostas a estas perguntas ser poss vel ao planejador estabelecer qual ser o impacto dos riscos sobre o projeto 2 2 ProJe o Dos Riscos A proje o ou estimativa de riscos permite definir basicamente duas quest es Qual a probabilidade de que o risco ocorra durante o projeto Quais as consequ ncias dos problemas associados ao risco no caso de ocorr ncia do mesmo As respostas a estas quest es podem ser obtidas basicamente a partir de quatro atividades estabelecimento de uma escala que reflita a probabilidade estimada de ocorr ncia de um risco estabelecimento das consequ ncias do risco estimativa do impacto do risco sobre o projeto e sobre o software produtividade e qualidade anota o da precis o global da proje o de riscos A escala pode ser definida segundo v rias representa es booleana qualitativa ou quantitativa No limite cada pergunta de uma dada checklist pode ser respondida com sim ou n o mas nem sempre esta representa o permite representar as incertezas de modo real stico Uma outra forma de se representar seria utilizar uma escala de probabilidades qualitativas onde os valores seriam altamente improv vel improv vel moderado prov vel altamente prov vel A partir destes valores qualitativos seria poss vel realizar c lculos que melhor expressassem as probabilidades matem ticas de que certo risco viesse a ocorrer O pr ximo passo e
83. ados juntos num diagrama de rastro de eventos A figura 9 13 mostra o cen rio e o rastro de eventos para uma chamada telef nica Um estado uma abstra o dos valores dos atributos e das liga es de um objeto Um estado especifica a resposta do objeto eventos de entrada A resposta de um objeto um evento pode incluir uma a o ou uma mudan a de estado pelo objeto Um estado tem uma dura o ele ocupa um intervalo de tempo entre dois eventos Na defini o de estados pode se ignorar atributes que n o afetam o comportamento do objeto O estado caracterizado por um nome e uma descri o contendo a sequ ncia de eventos que leva ao estado a condi o que o caracteriza e os eventos aceitos neste estado com a a o que ocorre e o estado futuro O estado pode incluir os valores de suas liga es O diagrama de estados relaciona estados e eventos A mudan a de estado causada por um evento chamada de transi o A figura 9 14 mostra o diagrama de estados de uma linha telef nica Os diagramas de estado podem representar ciclos de vida uma vez com um estado inicial e um estado final que representam objetos com vida finita ou malhas continuas como na figura 9 14 Um modelo din mico uma cole o de diagramas de estado que interagem entre si atrav s de eventos compartilhados Uma condi o uma fun o booleana de valores objetos Condi es podem serem usados como guardas nas transi es sendo que uma transi o guard
84. ais tarefas devem ser realizadas a cada itera o sendo que as tarefas na lista podem representar inclusive redefini es de componentes j implementados em raz o de erros ou problemas detectados numa eventual etapa de an lise Projeto Implementa o Implementa o Implementa o I i An lise An lise An lise Figura 1 5 O modelo Desenvolvimento Iterativo 3 2 4 O Modelo Espiral Este modelo proposto em 1988 sugere uma organiza o das atividades em espiral a qual composta de diversos ciclos Como mostrado na figura 1 6 a dimens o vertical representa o custo acumulado na realiza o das diversas etapas a dimens o angular representa o avan o do desenvolvimento ao longo das etapas jo CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA Cada ciclo na espiral inicia com a identifica o dos objetivos e as diferentes alternativas para se atingir aqueles objetivos assim como as restri es impostas O pr ximo passo no ciclo a avalia o das diferentes alternativas com base nos objetivos fixados o que vai permitir tamb m definir incertezas e riscos de cada alternativa No passo seguinte o desenvolvimento de estrat gias permitindo resolver ou eliminar as incertezas levantadas anteriormente o que pode envolver atividades de prototipa o simula o avalia o de desempenho etc Finalmente o software desenvolvido e o planejamento dos pr ximos passos r
85. alternativas de prateleira disposi o aspectos como o desempenho custo e disponibilidade s o de f cil obten o A Engenharia de Hardware baseada na execu o de tr s principais fases o Planejamento e a Especifica o cujo objetivo estabelecer a dimens o do esfor o necess rio ao desenvolvimento assim como o estabelecimento de um roteiro para o projeto e implementa o do hardware ainda nesta fase conduzida a an lise de requisitos cujo resultado deve ser uma especifica o a mais completa poss vel das fun es e outros requisitos para o hardware e das suas restri es o Projeto e Prototipa o a qual consiste na fase que com base nos requisitos e restri es especificadas na fase anterior define uma configura o preliminar do hardware atualmente as tarefas relativas a esta fase s o semi ou completamente automatizadas com o aux lio de ferramentas de software CAE CAD o resultado final desta fase um prot tipo montado que ser testado para garantir a satisfa o de todos os requisitos a Produ o Distribui o e Instala o onde o prot tipo obtido na fase anterior vai sofrer as evolu es para tornar se verdadeiramente um produto de hardware altera es na embalagem interfaces componentes etc s o ent o realizadas defini o de m todos de controle de qualidade um ponto fundamental nesta fase a cria o de um estoque de pe as de reposi o uma outra preoc
86. ama na nota o adotada os sub diagramas s o separados por linhas pontilhadas 4 2 5 Modelagem din mica avan ada A es de entrada e sa da Como alternativa a mostra a es nas transi es pode se associar a es com a entrada ou a sa da de um estado O nome da a o de entrada seguindo entry na caixa representando o estado e o nome da a o de sa da seguindo exit nesta s o as nota es adotadas A es internas Um evento pode for ar uma a o a ser realizada sem causar uma mudan a de estado o nome do evento escrito na caixa representando o estado seguido por um e o nome da a o A figura 9 16 representa a nota o utilizada para os diagramas de estado Transi o autom tica Existe a possibilidade de representar transi es autom ticas que disparam quando a atividade associada ao estado fonte completado representado por uma seta sem nome de evento No caso do estado n o ter atividade associada a transi o sem nome dispara logo ap s ter entrado no estado Chama se este tipo de transi o autom tica de lambda A transi o Eventos de envio Um objeto pode realizar uma a o de enviar um evento a um outro objeto Um sistema de objetos interage entre si Na nota o OMT pode se utilizar a palavra Send ou uma linha pontilhada que leva da transi o a um objeto conforme indicado na figura 9 16 gjy CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA
87. antes de um objeto vis o externa o que e o que ele faz ignorando suas caracter sticas internas vis o interna como ele deve ser implementado 2 5 ncarsuLamento O encapsulamento o empacotamento de dados atributos e de opera es sobre estes m todos No caso da orienta o a objetos os dados n o podem ser acessados diretamente mas atrav s de mensagens enviadas para as opera es A implementa o de um objeto pode ser mudada sem modificar a forma de acessa lo 2 6 Heran a A heran a consiste no compartilhamento de atributos e opera es entre as classes numa rela o hier rquica Este mecanismo permite a uma classe ser gerada a partir de classes j existentes por exemplo a classe autom vel herda da classe ve culo algumas propriedades e opera es Uma classe pode ser definida de forma abrangente como no caso do exemplo anterior e posteriormente refinada em termos de sub classes e assim sucessivamente Cada subclasse herda todas as propriedades e opera es da sua superclasse que n o precisam ser repetidas adicionando apenas as suas especificas Esta rela o entre classes uma das grandes vantagens de sistemas orientados a objetos por causa da redu o de trabalho resultante durante o projeto e a programa o destes Existem dois tipos de heran a e heran a simples ondeuma subclasse tem somente uma superclasse e heran a m ltipla na qual uma subclasse herda simultaneamente de v rias su
88. apas de desenvolvimento Primeiramente como forma de identificar precisamente o fim de uma etapa de o in cio da J4 seguinte um mecanismo de certifica o ou revis o implementado ao final de cada me CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA etapa isto feito normalmente atrav s da aplica o de algum m todo de valida o ou verifica o cujo objetivo ser garantir de que a sa da de uma dada etapa coerente com a sua entrada a qual j a sa da da etapa precedente Isto significa que ao final de cada etapa realizada deve existir um resultado ou sa da a qual possa ser submetida atividade de certifica o Estas sa das obtidas ao final de cada etapa s o vistas como produtos intermedi rios e apresentam se normalmente na forma de documentos documento de especifica o de requisitos documento de projeto do sistema etc Outra caracter stica importante deste modelo que as sa das de uma etapa s o as entradas da seguinte o que significa que uma vez definidas elas n o devem em hip tese alguma ser modificadas Duas diretivas importantes que norteiam o desenvolvimento segundo o modelo Queda d Agua s o e todas as etapas definidas no modelo devem ser realizadas isto porque em projetos de grande complexidade a realiza o formal destas vai determinar o sucesso ou n o do desenvolvimento a realiza o informal e impl cita de algumas destas et
89. apas poderia ser feita apenas no caso de projetos de pequeno porte e a ordena o das etapas na forma como foi apresentada deve ser rigorosamente respeitada apesar de que esta diretiva poderia ser questionada a ordena o proposta pelo modelo por ser a forma mais simples de desenvolver tem sido tamb m a mais adotada a n vel de projetos de software importante lembrar tamb m que os resultados de um processo de desenvolvimento de software n o devem ser exclusivamente o programa execut vel e a documenta o associada Existe uma quantidade importante de resultados ou produtos intermedi rios os quais s o importantes para o sucesso do desenvolvimento Baseados nas etapas apresentadas na figura 1 3 poss vel listar os resultados m nimos esperados de um processo de desenvolvimento baseado neste modelo Documento de Especifica o de Requisitos Projeto do Sistema Plano de Teste e Relat rio de Testes C digo Final Manuais de Utiliza o Relat rios de Revis es Apesar de ser um modelo bastante popular pode se apontar algumas limita es apresentadas por este modelo e o modelo assume que os requisitos s o inalterados ao longo do desenvolvimento isto em boa parte dos casos n o verdadeira uma vez que nem todos os requisitos s o completamente definidos na etapa de an lise e muitas vezes a defini o dos requisitos pode conduzir defini o do hardware sobre o qual o sistema vai funcionar dado que muitos projet
90. ar as tarefas definidas e refinadas nas etapas anteriores Na etapa de Codifica o que o nome que daremos ao conjunto de atividades relacionadas a esta formaliza o feito uso de linguagens de programa o como forma de expressar numa forma mais pr xima da linguagem processada pela m quina os aspectos definidos nas etapas precedentes Num processo de desenvolvimento de software onde os princ pios e metodologias da Engenharia de Software sejam aplicados corretamente a codifica o vista como uma consequ ncia natural do projeto Entretanto n o se deve deixar de lado a import ncia das caracter sticas da linguagem de programa o escolhida nesta etapa nem o estilo de codifica o adotado 2 A TRADU O Na etapa de codifica o o programador procura mapear corretamente as representa es ou modelos obtidos no projeto detalhado nas constru es suportadas por uma dada linguagem de programa o O resultado deste mapeamento constitui o c digo fonte o qual ser na seq ncia traduzido por um compilador gerando o c digo objeto Finalmente o c digo objeto ser mapeado nas instru es execut veis pelo microprocessador que comp e o sistema computacional resultando no c digo de m quina Ainda em grande parte dos casos o primeiro n vel de mapeamento obtido de forma manual ou semi automatizada estando sujeito portanto a ru dos inerentes do processo Alguns exemplos de ru dos s o interpr
91. ar que o erro volte a ocorrer 1 2 PRoceDImento DO teste De unIDaDe O teste de unidade considerado uma atividade vinculada codifica o Uma vez desenvolvido o c digo fonte os casos de teste devem ser projetados O projeto dos casos de teste pode ser uma consequ ncia da revis o do c digo fonte da unidade o que vai permitir estabelecer as condi es para analizar a unidade segundo os diferentes pontos de vista citados acima Parte do projeto dos casos de teste deve ser tamb m a especifica o dos resultados esperados em cada um deles As unidades de software n o s o programas aut nomos sendo dependentes de outras unidades Por esta raz o o teste de unidade exige a defini o de m dulos de software espec ficos denominados Drivers ou Stubs Como pode ser observado na figura 8 2 um driver faz o papel numa vers o bastante simplificada do programa principal ou de uma unidade de n vel superior que ativa a unidade a ser testada comunicando se com ela atrav s da interface imprimindo dados que sejam importantes para a tarefa de an lise daquela unidade Os stubs s o constru dos para desempenhar o papel das unidades de n vel mais baixo ou mesmo de componentes de hardware do sistema com o fim de viabilizar a execu o da unidade sob teste Tanto os drivers quanto os stubs s o programas adicionais a serem desenvolvidos e por esta raz o devem ser escritos da forma mais simples poss vel para minimizar o esfor o adiciona
92. astante elevado representando um grande obst culo para o sucesso completo desta atividade 3 MODALIDADES De teste 3 1 Testes est ticos e pm mucos Uma primeira divis o que pode ser estabelecida em rela o ao teste de software corresponde forma de utiliza o do c digo obtido na etapa de implementa o ou codifica o Segundo esta tica pode se organizar os testes em est ticos e din micos 8 3 CAP 8 TESTE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 3 1 1 Os Testes Est ticos Os testes est ticos s o aqueles realizados sobre o c digo fonte do software utilizando como t cnica b sica a inspe o visual Este tipo de teste de simples implementa o uma vez que n o h necessidade de execu o do programa para obter se resultados Eles podem ser utilizados utilizando a t cnica de leitura cruzada onde um leitor atribu do para avaliar o trabalho de cada programador do software Uma outra forma de realizar o teste por inspe o onde uma equipe designada analisa o c digo luz de um question rio especialmente concebido a check list Nos dois casos os respons veis pela realiza o do teste n o realizam nenhum tipo de corre o no c digo limitando se a assinalar os erros encontrados Eventualmente o teste est tico pode ser automatizado com o aux lio de ferramentas de an lise est tica que podem ser simples geradores de refer ncias cruzadas ou no caso de ferramentas mais
93. blema As entradas de condi es servem para combinar as condi es com as regras de decis o estabelecidas na parte superior da tabela O quadrante de a es define todas as a es que dever o ser tomadas como resposta s regras de decis o As entradas de a o relaciona as regras de decis o s a es A figura 5 9 ilustra o formato padr o de uma tabela de decis o A figura 5 10 apresenta um exemplo de uma tabela de decis es com entradas limitadas As entradas poss veis s o S N e X que denotam respectivamente SIM NAO TANTO FAZ e REALIZE A A O Como se pode verificar na figura um determinado empr stimo autorizado nas seguintes situa es se o limite de cr dito n o foi ultrapassado se o limite foi ultrapassado mas a experi ncia de pagamentos positiva se uma libera o especial de cr dito pode ser obtida Em outras condi es a ordem rejeitada As entradas S N e em cada coluna caracterizam uma regra de decis o Caso duas ou mais regras tenham as entradas id nticas a tabela considerada amb gua Regras de Decis o Quadr de Condi es mo Entradas de Condi es Quadrante de A es Entradas de A es Figura 5 9 Formato geral de uma tabela de decis es 515 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA Regras de Decis o Regra 4 Limite de cr dito satisfat rio N Experi ncia de pagamentos favor vel N Libera o especial obtida
94. bsistemas fundamental para as etapas posteriores de integra o dos diferentes componentes N o se deve negligenciar o fato de que muitos subsistemas podem ser adquiridos em lugar de serem desenvolvidos e mesmo aqueles que s o especialmente constru dos no contexto de um projeto usualmente s o desenvolvidos por diferentes equipes ou por diferentes empresas Qualquer m defini o neste item pode comprometer o sucesso do projeto ou implicar num aumento de custo ou de prazo de desenvolvimento As linhas contendo setas nas duas dire es entre cada par de passos sugere a necessidade de revis es e realimenta es em cada passo Na maioria dos projetos o n mero de solu es poss veis bastante grande podendo se chegar a diferentes vis es de como as fun es s o alocadas a subsistemas de hardware de software ou aos elementos humanos que v o interagir com o sistema A escolha da solu o a ser encaminhada vai ser feita em fun o de crit rios t cnicos mas tamb m ter influ ncia de crit rios pol ticos e organizacionais da institui o No caso de projetos desenvolvidos para institui es militares por exemplo fornecedores nacionais ser o escolhidos em lugar de fornecedores estrangeiros mesmo que em termos t cnicos a solu o oferecida n o seja a ideal 3 9 CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA 3 3 DesenyoLy mento Dos SuBsIstemas Esta etapa agrupa as atividad
95. ca o de Requisitos Dentre estas caracter sticas podemos relacionar o uso de uma linguagem gr fica de comunica o e a possibilidade de representa o de um problema obedecendo a uma pol tica de decomposi o estruturada de cima para baixo top down limitar a quantidade de informa es podendo conter num dado n vel de representa o de um problema segundo os limites que a mente humana pode absorver permitir a representa o de um problema segundo dois pontos de vista o ponto de vista das atividades e ponto de vista dos dados o que satisfaz a um dos princ pios importantes da An lise de Requisitos que o princ pio da proje o Um modelo SADT consiste de um conjunto ordenado de diagramas onde cada diagrama tra ado numa p gina nica Um diagrama composto em m dia de tr s a seis blocos interconectados por um conjunto de arcos dirigidos 8 2 1 A Linguagem de Representa o Gr fica O princ pio que rege o modelo SADT o fato de que o conhecimento sobre o mundo e seus sistemas fundamento sobre coisas e acontecimentos ou melhor de objetos e eventos ou ainda de dados e atividades A linguagem de representa o proposta no SADT baseada na constru o de um conjunto de diagramas onde os elementos b sicos s o os blocos e as setas O tipo de informa o representado pelas setas depende do tipo de diagrama constru do no modelo 5 17 CAP 5 AN LISE DE REQUISITOS PROF VIT
96. cia de algum problema relacionado interface dos diferentes subsistemas uma solicita o de modifica o no sistema pode ser necess ria Em sistemas envolvendo a utiliza o de muitos subsistemas de hardware a realiza o de modifica es ap s o t rmino da implementa o podem representar um aumento consider vel no custo de desenvolvimento Uma forma bastante utilizada nos projetos neste caso utilizar os subsistemas de software para facilitar estas modifica es devido particularmente flexibilidade inerente dos sistemas de software E l gico que para que as modifica es nos subsistemas de software n o representem custos t o elevados ou maiores quanto o dos subsistemas de hardware necess rio que estes subsistemas tenham sido concebidos tendo como princ pio sua manutenibilidade 3 4 Integra o Do Sistema O conjunto de atividades a ser desenvolvido nesta etapa o de conex o dos diferentes subsistemas constru dos ou adquiridos para compor o sistema E uma atividade bastante complexa devido principalmente grande diversidade de tecnologias envolvidas na concep o dos diferentes sistemas Um problema comumente encontrado nesta etapa o mal funcionamento de um subsistema como consequ ncia de uma defini o imprecisa de funcionalidade de outro subsistema i CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF Vit rio BRUNO MAZZOLA Uma forma de realizar a integra o de um sistema o process
97. como ele pensa que dever ser a sua intera o com o software os objetos da aplica o que ele considera importantes e que devem portanto ser ressaltados as opera es que ele desejar realizar sobre os objetos do sistema comoele pretende visualizar estes objetos na interface do software etc A imagem do sistema uma representa o do implementador do que o soft ware vai oferecer como interface e todo o material de apoio utiliza o manuais videotapes livros etc A coincid ncia entre a percep o d o sistema e a imagem do sistema n o um acontecimento bvio mas quanto mais pr ximos estiv erem estes modelos mais chances se ter de projetar uma interface que venha satisfazeraos anseios de seus usu rios e que viabilize a utiliza o efetiva do software O trabalho do projetista o de definir os aspectos de interface luz dos modelos produzidos procurando harmonizar os desejos dos usu rios com as limita es impostas pelas t cnicas e ferramentas dispon veis e pelos crit rios de projeto do software g CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 6 2 2 An lise e Modelagem de Tarefa Como se p de verificar nas discuss es relativas ao projeto num contexto mais geral as atividades de s ntese no caso as atividades de projeto s o antecedidas por atividades de an lise no caso a an lise de requisitos Ainda como j foi citado os softwares s o introduzidos nos sistemas co
98. componentes capazes de adaptar uma forma de representa o de informa o na forma de representa o utilizada pelo componente que vai process la Exemplos deste tipo de componente s o uma placa de v deo um conversor anal gico digital etc A figura 3 5 mostra atrav s de um sistema de seguran a dom stica como podem ser classificados os diferentes componentes o que explicitado na tabela a seguir Classe Componente Fun o Sensor Sensor de movimento e da porta Detectar intrus o 815 CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF Vit rio BRUNO MAZZOLA Atuador Sirene Comunica o Ativador de chamada telef nica Coordena o Controlador do alarme Interface Sintetizador de voz Gerar um sinal de alarme Realizar chamada a um sistema externo Coordenar os demais componentes Gerar mensagem de localiza o Sensores de Sensores das Movimento Portas Controlador do alarme Sirene Sintetizador de Ativador de para um sistema voz chamada telef nico externo Figura 3 5 Sistema de seguran a dom stica 816 Engenharia de Software CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA Car tuLo 4 PLANeJAamento Do DesenvoLvImento De SOFARE 1 INTRODU O Na maior parte dos trabalhos de engenharia e os trabalhos de Engenharia de Software n o fazem exce o o tempo
99. conex o f sica ou conceitual entre inst ncias de objetos Por exemplo Vit rio Mazzola trabalha para UFSC Uma liga o uma t pla matem tica correspondente a uma lista ordenada de inst ncias de objetos Uma liga o uma inst ncia de uma associa o 9 6 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA Uma associa o ou association descreve um grupo de liga es com estrutura e sem ntica comuns Por exemplo uma pessoa trabalha para uma institui o Todas as liga es de uma associa o conectam objetos das mesmas classes O conceito de associa o similar aquele usado na rea de base de dados Associa es e liga es s o descritas por verbos Associa es s o inerentemente bidirecionais e podem ser lidas nos dois sentidos Por exemplo num primeiro sentido pode se ler Vit rio Mazzola trabalha para UFSC e no sentido inverso UFSC emprega Vit rio Mazzola Associa es s o muitas vezes implementadas em linguagens de programa o como apontadores atributo de um objeto que cont m referencia expl cita a um outro de um objeto para outro Por exemplo objeto Pessoa pode conter atributo empregado que aponta para um conjunto de objetos Institui o Uma liga o mostra a rela o entre 2 ou mais objetos A figura 9 5 mostra uma associa o um a um e as liga es correspondentes Observa se na nota o OMT que a associa o corresponde a uma linha entre classes e
100. corr ncia destas transforma es Um modelo realizado durante a etapa de An lise de Requisitos deve concentrar se na representa o do que o software deve realizar e n o em como ele o realiza Normalmente desej vel que os modelos sejam expressos atrav s de uma nota o gr fica que permita descrever os diferentes aspectos citados no par grafo anterior Nada impede por m que um modelo seja dotado de descri es textuais complementares sendo que normalmente estas descri es devem ser realizadas ou por meio de linguagem natural ou de uma linguagem especializada que permita expressar sem ambig idades os requisitos estabelecidos A obten o de um modelo representativo dos requisitos do software pode ser til s diferentes partes envolvidas no desenvolvimento do software ao analista para uma melhor compreens o da informa o as fun es e o comportamento do sistema o que pode tornar a tarefa de an lise mais sistem tica ao pessoal t cnico como um todo uma vez que ele pode ser uma refer ncia de revis o permitindo a verifica o de algumas propriedades como a completude a coer ncia e a precis o da especifica o ao projetista servindo de base para o projeto atrav s da representa o dos aspectos essenciais do software 1 3 PaRtcionamento Em boa parte das vezes os problemas a serem resolvidos s o excessivamente complexos apresentando grande dificuldade para a sua compreens o e consequente
101. cos ou softwares que exijam a utiliza o de algoritmos combinat rios podem ser objeto de prototipa o no entanto o fator complexidade deve permitir determinar a realiza o ou n o do prot tipo outro ponto que deve ser pesado nesta decis o se a equipe de desenvolvimento tem experi ncia e ferramentas adequadas prototipa o especifica o resumida dos requisitos realizada pelo analista de modo a representar o dom nio da informa o e os dom nios funcionais e comportamentais do software de modo que a atividade de particionamento do problema possa ser efetuada revisada a especifica o resumida dos requisitos realizado um projeto do prot tipo concentrando se principalmente nos aspectos arquitet nicos e de dados e deixando de lado os aspectos procedimentais e desenvolvimento do prot tipo se poss vel a partir da utiliza o de blocos de constru o de software preexistentes o que na maioria dos casos s o de dif cil obten o por outro lado a constru o de um prot tipo pode ser facilitada gra as exist ncia de diversas ferramentas orientadas a esta atividade apresenta o do prot tipo testado ao cliente para que este possa efetuar sua avalia o a partir desta avalia o o cliente pode sugerir extens es ou reformular alguns requisitos de modo a que o software possa melhor corresponder s reais necessidades repeti o iterativa dos dois passos anteriores at que todos os requisit
102. de Resposta do Software 4 4 Considera es Especiais 5 0 Bibliografia 6 0 Ap ndices Figura 5 3 Estrutura do documento de Especifica o de Requisitos A se o de Descri o da Informa o deve apresentar informa es sobre o problema que o software deve resolver Os fluxos e a estrutura das informa es devem ser descritos nesta se o utilizando um formalismo adequado como por exemplo os DFDs e os Dicion rios de Dados assim como os elementos relacionados s interfaces internas e externas do software incluindo hardware elementos humanos outros softwares etc A se o seguinte Descri o Funcional apresenta as informa es relativas s fun es a serem providas pelo software incluindo uma descri o dos processamentos envolvidos no funcionamento do software Ainda nesta se o devem ser apresentadas as restri es de projeto detectadas nesta etapa A se o de Crit rios de Valida o que apesar de ser a mais importante aquela sobre a qual menor aten o dispensada vai estabelecer os par metros que permitir o avaliar se a implementa o do software vai corresponder solu o desejada para o problema Definir os crit rios de valida o significa ter um entendimento completo dos requisitos funcionais e de processamento de informa o do software Uma defini o importante a ser encaminhada nesta se o o conjunto de testes que dever ser aplicado implementa o para que se t
103. de m quina representa a linguagem interpretada pelos microprocessadores sendo que cada microprocessador caracterizado por uma linguagem de m quina pr pria podendo eventualmente O CAP 7 LINGUAGENS DE PROGRAMA O PROF Vit rio BRUNO MAZZOLA estabelecer se certa compatibilidade em software entre microprocessadores de uma mesma fam lia fabricante Embora tendo seu uso bastante limitado alguns programas ainda s o realizados utilizando o c digo de m quina ou mais precisamente seu equivalente leg vel a linguagem Assembly Numa tica de Engenharia de Software a programa o atrav s de linguagens desta classe limitam se a situa es onde a linguagem de alto n vel adotada para a programa o n o suporte alguns requisitos especificados 4 2 Lmewacens ne Segunda Gera o As linguagens de segunda gera o constituem as primeiras linguagens de alto n vel que surgiram entre o final da d cada de 50 e in cio dos anos 60 Linguagens como Fortran Cobol Algol e Basic com todas as defici ncias que se pode apontar atualmente foram linguagens que marcaram presen a no desenvolvimento de programas sendo que algumas delas t m resistido ao tempo e s cr ticas como por exemplo Fortran que ainda visto como uma linguagem de implementa o para muitas aplica es de engenharia Cobol por outro lado ainda uma linguagem bastante utilizada no desenvolvimento de aplica es comerciais 4 3
104. de representa o de um diagrama Os diagramas dever o ser apresentados em folhas de formato normalizado observando a configura o mostrada na figura 5 20 Dentro de um diagrama pai um bloco pai referenciado da seguinte forma ver figura 5 21 o n mero do bloco posicionado em baixo direita de cada bloco e a refer ncia do diagrama filho que representa o refinamento do bloco posicionado abaixo do bloco esta refer ncia representa a p gina do documento de diagramas onde o refinamento do bloco est apresentado a aus ncia de refer ncia implica na n o exist ncia de um refinamento daquele bloco Nome do Projeto ETAPA LEITOR DATA proposa 1 Refer ncia T TULO DO BLOCO PAI Ref a Diag NO Figura 5 20 Folha padr o para constru o do diagrama Rp13 n do bloco N ref do diagrama filho Figura 5 21 Refer ncias dos blocos num diagrama 5 23 Engenharia de Software CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA Car tuLo 6 PRoJeto De SOFTWARE 1 INTRODU O A etapa de Projeto o passo inicial de uma nova fase do ciclo de vida do software a fase de Desenvolvimento O Projeto consiste na aplica o de um conjunto de t cnicas e princ pios de modo a definir um sistema num n vel de detalhe suficiente sua realiza o f sica A tarefa do projetista nada mais do que produzir um modelo de representa o do software que ser implementado
105. de software podem ser especificados segundo dois crit rios dependendo do grau de conhecimento que se tem do sistema ou dependendo do est gio de an lise no qual nos encontramos O primeiro crit rio o da concep o essencial onde o objetivo contemplar os aspectos essenciais do problema sob an lise sem preocupa o com detalhes de implementa o Considerando o exemplo de problema ilustrado nas figuras 5 1 e 5 2 a concep o essencial da fun o ler status ignora o formato dos dados de status ou o tipo de sensor que ser utilizado A vantagem de realizar a concep o essencial de deixar em aberto as alternativas de implementa o poss veis o que adequado para as atividades iniciais do desenvolvimento O segundo crit rio o da concep o de implementa o o qual permite expressar os requisitos do software segundo as fun es de processamento e as estruturas de informa o do sistema real Software de Seguran a Dom stica Configurar sistema Monitorar Sensores Interagir com usu rios PARTICIONAMENTO HORIZONTAL Figura 5 1 Ilustra o da abordagem horizontal de particionamento Software de Seguran a Dom stica Configurar sistema Monitorar Sensores Interagir com usu rios PARTICIONAMENTO VERTICAL Varrer eventos Ativar alarme Ler status Identificar evento Alarme sonoro Discar telefone Figura 5 2 Ilustra o da abordagem vertical de particionamento Em alguns casos uma representa o f sica
106. de tr s grandes fases a fase de defini o a fase de desenvolvimento e a fase de manuten o as quais ser o discutidas nas se es abaixo 1 Fase De Dermi o A fase de defini o est associada determina o do que vai ser feito Nesta fase o profissional encarregado do desenvolvimento do software deve identificar as informa es que dever o ser manipuladas as fun es a serem processadas qual o n vel de desempenho desejado que interfaces devem ser oferecidas as restri es do projeto e os crit rios de valida o Isto ter de ser feito n o importando o modelo de desenvolvimento adotado para o software e independente da t cnica utilizada pra faz lo Esta fase caracterizada pela realiza o de tr s etapas espec ficas e a An lise ou Defini o do Sistema a qual vai permitir determinar o papel de cada elemento hardware software equipamentos pessoas no sistema cujo objetivo determinar como resultado principal as fun es atribu das ao software e o Planejamento do Projeto de Software no qual a partir da defini o do escopo do software ser feita uma an lise de riscos e a defini o dos recursos custos e a programa o do processo de desenvolvimento e a An lise de Requisitos que vai permitir determinar o conjunto das fun es a serem realizadas assim como as principais estruturas de informa o a serem processadas La Fase De Desenvolvimento Nesta fase ser determinado como
107. dena o e supervis o de todas as atividades relativas ao desenvolvimento do software e o pessoal t cnico de dois a cinco membros que realizam as atividades de an lise e desenvolvimento um engenheiro substituto que atua no apoio ao engenheiro s nior e que pode eventualmente substitu lo sem grandes preju zos ao desenvolvimento do software Al m deste n cleo a equipe de desenvolvimento pode ainda receber a colabora o dos seguintes elementos um conjunto de especialistas telecomunica es bancos de dados interface homem m quina etc pessoal de apoio secret rias editores t cnicos desenhistas etc um bibliotec rio o qual ser respons vel da organiza o e cataloga o de todos os componentes do produto de software documentos listagens m dia magn tica coleta de dados relativos ao projeto m dulos reutiliz veis etc 7 M TRICA DO SOFTWARE 7 1 Import ncia Da M trica Em primeiro lugar importante estar ciente que as medidas s o uma forma clara de avalia o da produtividade no desenvolvimento de software Sem informa es quantitativas a respeito do processo de desenvolvimento de softwares por parte de uma empresa ou equipe de desenvolvedores de produto imposs vel tirar qualquer conclus o sobre de que forma est evoluindo a produtividade se que est evoluindo Atrav s da obten o de medidas relativas produtividade e qualidade poss vel que m
108. devem ser registrados e confrontados aos valores especificados 7 2 O veste De seguran a O teste de seguran a visa garantir que o sistema n o vai provocar danos recuper veis ou n o ao sistema pela sua pr pria a o Por exemplo num sistema de informa o acad mica um aluno deve ter autoriza o de acesso para a visualiza o das notas obtidas nas disciplinas que cursou hist rico escolar mas n o deve ter a possibilidade de alterar seus valores No teste de seguran a o analista deve desempenhar um papel semelhante ao de um hacker tentando contornar todos os mecanismos de seguran a implementados no mesmo As a es a experimentar s o as mais diversas derrubar o sistema como um todo acessar informa es confidenciais modificar informa es de bases de dados interferir no funcionamento do sistema introduzir v rus de computador no sistema sobrecarregar o sistema pela multiplica o de processos executando etc fe CAP 8 TESTE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 7 3 O teste De estresse O teste de estresse como o nome indica consiste em verificar como o sistema vai se comportar em situa es limite Este limite pode ser verificado sob diferentes pontos de vista dependendo das caracter sticas do software Alguns aspectos que podem ser observados neste contexto s o e limite em termos de quantidade de usu rios conectados a um determinado sistema servidor quantidade de utiliza o
109. do a introdu o de coment rios ao longo do c digo fonte Na realidade este um aspecto bastante pol mico mas este mecanismo pode ser bastante til se utilizado eficientemente podendo transformar se no principal aliado s tarefas de manuten o Uma sistem tica interessante de uso dos coment rios a compatibiliza o destes com a documenta o de projeto do software Um ltimo aspecto importante na documenta o a formata o do c digo fonte Um mecanismo importante neste contexto o uso da endenta o como meio de melhor posicionar as instru es no contexto de trechos significativos do c digo A endenta o permite explicitar melhor a combina o dos blocos b sicos de uma linguagem de programa o as estruturas cl ssicas de controle para a composi o de componentes mais complexos No que diz respeito a este aspecto muitas ferramentas CASE oferecem os chamados formatadores autom ticos de c digo os quais liberam o programador desta preocupa o 7 8 CAP 7 LINGUAGENS DE PROGRAMA O PROF Vit rio BRUNO MAZZOLA 5 2 R Declara o De Danos Este aspecto nem sempre objeto de preocupa o por parte dos programadores mas medida que o programa vai se tornando complexo no que diz respeito defini o de estruturas de dados o estabelecimento de uma sistem tica padronizada de declara o de tipos de dados e vari veis vai assumindo um n vel cada vez maior de import ncia A ling
110. do das entradas para as sa das ou vice versa procurando definir as principais poucas em princ pio transforma es de dados refinando em seguida estas transforma es em conjuntos de transforma es mais espec ficas evitar sempre a express o de fluxo de controle eliminar da an lise qualquer racioc nio que sugira decis o ou malhas e rotular as setas com os nomes dos dados apropriados entradas e sa das de cada transforma o devem ser cuidadosamente identificadas e utilizar os operadores e sempre que necess rio quando poss vel tra ar diversos DFDs de um mesmo problema ao inv s de adotar o primeiro constru do 7 2 O Dicion rio De Danos Num DFD os dados s o identificados por um r tulo nico que represente claramente o significado da informa o Por outro lado a defini o da estrutura de dados que vai representar a informa o n o feita a n vel do DFD Para isto constru do um Dicion rio de Dados o qual se constitui de um dep sito de todos os fluxos de dados explicitados no DFD associado Os componentes de um fluxo de dados do DFD podem ser ent o especificados no dicion rio de dados assim como a estrutura dos eventuais arquivos definidos no diagrama As nota es mais diversas podem ser utilizadas para definir as estruturas dos dados sendo que uma proposta de nota o poss vel inclui as seguintes informa es nome o identificador principal do item de dados do dep sito de da
111. do na tela eventualmente uma combina o dos dois pode ser uma boa solu o redund ncia uso eficiente do espa o da tela particularmente em interfaces baseadas no uso de m ltiplas janelas a disposi o destas deve ser tal que pelo menos uma parte de cada janela continue sendo visualizada caso contr rio definir um mecanismo que permita fazer rapidamente o chaveamento entre janelas menu Janelas ou comandos de teclado ALT TAB por exemplo 6 3 3 A Entrada de Dados Durante a utiliza o de um software com alto n vel de interatividade o usu rio passa boa parte do seu tempo fazendo a escolha de comandos e inserindo dados de processamento De forma a melhorar as condi es nas quais estas intera es ocorrem os seguintes princ pios devem ser considerados minimiza o do n mero de a es necess rias entrada de dados reduzindo principalmente a quantidade de texto a ser digitada um recurso interessante para esta redu o o uso de recursos gr ficos sens veis ao mouse como por exemplo escalas vari veis a coer ncia visual da interface em rela o s entradas mantendo cores tamanhos e formas compat veis com o restante da interface configura o da entrada por parte do usu rio permitindo minimizar em fun o das habilidades do usu rio etapas na entrada dos dados por exemplo eliminar quadros de informa o sobre como o usu rio deve proceder para executar determinado comando ou defin
112. dor do erro Por esta raz o importante que o Engenheiro de Software tente prever potenciais problemas de integra o a outros elementos do sistema e inclua no software caminhos de tratamento de erros para este sistema Por exemplo num software de comunica o podem ser inclu dos m dulos de tratamento de erros que informem quando um determinado dispositivo de E S n o est respondendo corretamente O teste de sistema inclui diversas modalidades de teste cujo objetivo testar o sistema computacional como um todo Embora cada teste tenha uma finalidade diferente o objetivo global acaba sendo atingido uma vez que estes abrangem todos os elementos constituintes do sistema verificando se estes foram adequadamente integrados 7 1 O veste De Recurera o Neste tipo de teste o objetivo observar a capacidade do sistema para recuperar se da ocorr ncia de falhas num tempo previamente determinado Em alguns casos cada vez mais frequentes exige se que o sistema seja tolerante a falhas ou seja que nele seja previsto processamento que permita retomar seu funcionamento mesmo no caso de ocorr ncia de algumas falhas Neste tipo de teste falhas s o provocadas artificialmente por uma t cnica denominada inje o de falhas de modo a analisar a capacidade do sistema do ponto de vista da recupera o Os valores de tempo exigido para recupera o do sistema seja por a o autom tica ou devido interven o de um operador humano
113. dos etc evitando a ocorr ncia de funcionamento anormal relacionado a robustez categoriza o das atividades organizando a tela segundo a classifica o escolhida opera es de arquivos opera es de edi o ajuda formata o configura es etc oferecimento de facilidades de ajuda sens veis ao contexto nomea o de comandos atrav s de verbos ou express es verbais simples 6 3 2 A Exibi o de Informa es Com rela o exibi o de informa es os seguintes aspectos devem ser observados a concis o ou seja mostrar apenas informa es relevantes ao contexto do sistema priorizar a utiliza o de s mbolos gr ficos para a express o de informa es quando houver possibilidade precis o com rela o s mensagens de erro permitindo que o usu rio possa tomar alguma a o que possa recuperar o erro ou que ele possa evitar uma situa o semelhante em informa es textuais o uso de letras mai sculas e min sculas pode facilitar o entendimento uso de janelas para separar diferentes tipos de informa o e utilizar displays an logos para representar valores de grandezas reais de um dado sistema por exemplo a utiliza o da figura de um term metro para indicar o valor da temperatura de uma determinada subst ncia mais significativa para um 6 16 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA usu rio do que um valor num rico desfilan
114. dos a problemas relacionados ao pr prio processo de desenvolvimento or amento cronograma pessoal etc riscos t cnicos que consistem dos problemas de projeto efetivamente implementa o manuten o interfaces plataformas de implementa o etc riscos de produto os quais est o mais relacionados aos problemas que v o surgir para a inser o do software como produto no mercado oferecimento de um produto que ningu m est interessado oferecer um produto ultrapassado produto inadequado venda etc A categoriza o dos riscos apesar de interessante n o garante a obten o de resultados satisfat rios uma vez que nem todos os riscos podem ser identificados facilmente Uma boa t cnica para conduzir a identifica o dos riscos de forma sistem tica o estabelecimento de um conjunto de quest es checklist relacionado a algum fator de qu CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA risco Por exemplo com rela o aos riscos de composi o da equipe de desenvolvimento as seguintes quest es poderiam ser formuladas s o os melhores profissionais dispon veis os profissionais apresentam a combina o certa de capacidades h pessoas suficientes na equipe os profissionais est o comprometidos durante toda a dura o do projeto algum membro da equipe estar em tempo parcial sobre o projeto os membros da equipe est o adequadamente trein
115. dos ou de uma entidade externa alias eventualmente outros nomes utilizados para o mesmo item utiliza o em que contexto onde e como o item de informa o utilizado descri o uma nota o que permita explicitar o conte do do item 5 12 CAP 5 AN LISE DE REQUISITOS PROF Vit rio BRUNO MAZZOLA informa es complementares a respeito do item de dados como valores iniciais restri es etc Atualmente a obten o do dicion rio de dados resultante do uso de uma ferramenta CASE sendo que esta pode inclusive checar a consist ncia da especifica o com rela o a esta aspecto da defini o Por exemplo caso o analista nomeie um item de dados rec m derivado com um identificador que j fa a parte do dicion rio a ferramenta devolve uma mensagem de erro indicando a duplica o do identificador Outro aspecto positivo do uso de uma ferramenta CASE a gera o de algumas informa es de forma automatizada A informa o utiliza o um exemplo disto uma vez que ela pode ser derivada a partir dos fluxos de dados Apresentamos abaixo o dicion rio de dados definido para alguns dos itens de dados apresentados no DFD da figura 5 7 nome matr cula_empregado alias nenhum utiliza o obt m arquivo empregado entrada descri o matricula_empregado d gito d gito d gito d gito nome pre o hora alias nenhum utiliza o obt m arquivo empregado entrada
116. dronizadas das linguagens de programa o ou sistemas operacionais isolar e comentar todos os aspectos do programa que envolvam a depend ncia do hardware 5 0 MODELO mm A causa mais comum do insucesso dos projetos de desenvolvimento de software a m utiliza o ou a completa indiferen a aos m todos e ferramentas orientados concep o E poss vel que em empresas de desenvolvimento de software onde o uso de metodologias consistentes n o seja pr tica adotada os projetos possam ter bons resultados Mas em geral estes bons resultados s o muito mais uma consequ ncia de esfor os individuais do que propriamente causadas pela exist ncia de uma pol tica e de uma infra estrutura adequada produ o de software O modelo CMM Capability Maturity Model foi definido pelo SEI Software Engineering Institute com o objetivo de estabelecer conceitos relacionados aos n veis de maturidade das empresas de desenvolvimento de software com respeito ao grau de evolu o que estas se encontram nos seus processos de desenvolvimento O modelo estabelece tamb m que provid ncias as empresas podem tomar para aumentarem gradualmente o seu grau de maturidade melhorando por consequ ncia sua produtividade e a qualidade do produto de software 5 1 Conceros B sicos Do CMM Um Processo de Desenvolvimento de Software corresponde ao conjunto de atividades m todos pr ticas e transforma es que uma equipe utiliza para desen
117. e as potencialidades do software um conjunto de princ pios deve ser observado N o existe uma f rmula tima para o desenvolvimento das interfaces mas em linhas gerais pode se classificar os princ pios sob tr s diferentes pontos de vista a intera o a exibi o de informa es e a entrada de dados 6 3 1 A Intera o No que diz respeito intera o pode se relacionar as seguintes diretrizes a coer ncia na defini o das escolhas do menu entradas de comandos e outras fun es importantes utiliza o de recursos visuais e auditivos nas respostas a comandos do usu rio exigir confirma o de qualquer a o destrutiva n o trivial elimina o de arquivos abandono do software altera es substanciais de configura o etc proteger eventualmente com senha a es que possam acarretar em consequ ncias catastr ficas para o sistema e possibilitar a revers o undo da maior parte das a es por exemplo um usu rio que selecione um bloco de texto a ser copiado e que digite acidentalmente uma tecla qualquer antes do comando de c pia pode perder parte do seu trabalho se n o houver a possibilidade de anula o da digita o redu o da quantidade de informa es a ser memorizada no intervalo entre a es e otimiza o de di logo definindo cuidadosamente o layout das telas e dos atalhos de teclado admiss o de erros do usu rio atalhos de teclado incorretos comandos e dados inadequa
118. e codifica o e testes onde o produto obtido pode apresentar um n vel de qualidade suspeito 2 8 CAP 2 QUALIDADE DE SOFTWARE PROF Vit rio BRUNO MAZZOLA Aperfei oamento cont nuo Processo previs vel Processo padronizado Processo disciplinado Figura 2 1 Os n veis de maturidade de um processo de desenvolvimento de software A capabilidade de uma empresa caracterizada como n vel 1 totalmente imprevis vel uma vez que o processo de desenvolvimento de software inst vel sujeito a mudan as radicais frequentes n o apenas de um projeto a outro mas tamb m durante a realiza o de um mesmo projeto Neste n vel estima o de custos prazos e qualidade do produto algo totalmente fora do contexto e da pol tica de desenvolvimento que pol tica Embora n o se possa assegurar o fracasso de um projeto desenvolvido por uma empresa situada neste n vel poss vel dizer que o sucesso geralmente resultado de esfor os individuais variando com as habilidades naturais o conhecimento e as motiva es dos profissionais envolvidos no projeto 5 2 2 N vei Reret vel Neste n vel pol ticas de desenvolvimento de software e tarefas de suporte a estas pol ticas s o estabelecidas o planejamento de novos projetos sendo baseado na experi ncia obtida com projetos anteriores Para que uma empresa possa atingir este n vel imprescind vel institucionalizar o gerenciamen
119. ealizado A continuidade do processo de desenvolvimento definida como fun o dos riscos remanescentes como por exemplo a decis o se os riscos relacionados ao desempenho ou interface s o mais importantes do que aqueles relacionados ao desenvolvimento do programa Com base nas decis es tomadas o pr ximo passo pode ser o desenvolvimento de um novo prot tipo que elimine os riscos considerados Por outro lado caso os riscos de desenvolvimento de programa sejam considerados os mais importantes e se o prot tipo obtido no passo corrente j resolve boa parte dos riscos ligados a desempenho e interface ent o o pr ximo passo pode ser simplesmente a evolu o segundo o modelo Queda d Agua Como se pode ver o elemento que conduz este processo essencialmente a considera o sobre os riscos o que permite de certo modo a adequa o a qualquer pol tica de desenvolvimento baseada em especifica o baseada em simula o baseada em prot tipo etc CUSTO ACUMULADO AVAN O Determina objetivos A Er Avalia alternativas alternativas e restri es identifica e resolve riscos An lise de Riscos gt An lis Je de Riscos lt Prot tipo Revis evis o Plano de Requisitos Plano de Ciclo Conceito de e Vida Opera o Plano de cado Desenvolvimento Valida o dos Requisitos Plano de e A Integra o e Testes Valida o e Veri Pr ximas etapa
120. ecessidade podem ser erros do pr prio sistema novas necessidades em termos de fun o ou altera es ambientais As evolu es a serem promovidas num dado sistema podem representar um custo bastante alto o que justificado pelas raz es abaixo e Necessidade de estudos relativos s modifica es a serem feitas para n o comprometer o bom funcionamento do sistema e O alto grau de depend ncia dos diversos subsistemas pode conduzir necessidade de altera es em muitos subsistemas como consequ ncia da altera o de um componente e A falta de documenta o relativa ao desenvolvimento do sistema original vai ser sem d vida um grande obst culo para o desenvolvimento do sistema e medida que o tempo passa e que altera es v o sendo realizadas a estrutura original dos sistemas vai sendo modificada de modo que futuras mudan as podem ser fortemente comprometidas 3 8 Desatva o Do Sistema Esta etapa consiste em retirar o sistema de opera o quando seu tempo previsto de funcionamento esgota ou quando ele ser substitu do por um novo sistema A desativa o deve ser feita de forma bastante rigorosa principalmente no caso de sistemas cujos componentes podem ser nocivos ao ambiente Sistemas que utilizam componentes radioativos s o os exemplos mais comuns de sistemas cuja desativa o deve ser feita com o maior cuidado poss vel Por outro lado no caso dos sistemas de software a desativa o pode ser extremam
121. ectos enquadram se nos par metros estabelecidos na especifica o de requisitos 2 descoberto um desvio das especifica es neste caso uma lista de defici ncias criada para relacionar de que forma ou quanto as caracter sticas do software obtido afasta se dos requisitos No caso de descoberta de erros estes dificilmente ser o corrigidos antes do per odo definido para a conclus o do programa Eventualmente uma negocia o extens o de prazo de entrega por exemplo dever ser realizada em conjunto com o cliente para possibilitar a elimina o destas defici ncias 6 2 Revis o De conrigura o Um aspecto de import ncia no processo de valida o a chamada revis o de configura o Ela consiste em garantir que todos os elementos de configura o do software tenham sido adequadamente desenvolvidos e catalogados corretamente com todos os detalhes necess rios que dever o servir de apoio fase de manuten o do software Esta revis o algumas vezes denominada auditoria est ilustrada na figura 8 5 gi CAP 8 TESTE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 6 3 testes ALFa e Beta Apesar do esfor o na valida o de um software na maioria das vezes extremamente dif cil para o desenvolvedor ou programador prever as diferentes maneiras como o software ser utilizado Principalmente no caso de softwares interativos os usu rios muitas vezes experimentam comandos e entradas de dados os mais di
122. egorias de componentes podem ser identificadas Abaixo ser o descritas aquelas mais frequentemente encontradas nos sistemas Sensores S o os elementos capazes de coletar informa es a respeito do ambiente onde o sistema est instalado Exemplos deste tipo de componente s o os radares do sistema de controle de tr fego a reo ou os sensores de posicionamento de papel numa impressora a laser ou jato de tinta Atuadores Estes componentes tem por fun o realizar a es no sistema ou em seu ambiente V lvulas para abertura ou fechamento de fluxo hidr ulico os flaps das asas do avi o o mecanismo de alimenta o de papel numa impressora s o exemplos desta classe de componentes Componentes computacionais S o os elementos capazes de exercer algum processamento de uma dada informa o de entrada para gerar um conjunto de informa es de sa da Alguns exemplos s o processadores gr ficos processadores aritm ticos um elemento que implemente um algoritmo de controle etc Componentes de comunica o S o os componentes que ir o viabilizar a comunica o entre partes de um sistema ou entre o sistema e seu ambiente Uma placa Ethernet uma porta serial um modem s o inst ncias de tal classe Componentes de Coordena o S o os componentes que executam as fun es de coordena o do sistema Um algoritmo de escalonamento num sistema tempo real um bom exemplo deste tipo de componente Componentes de interface S o os
123. elecer uma medida da qualidade um aspecto importante para a garantia de um produto de software com algumas das caracter sticas definidas anteriormente O Metrologia do Software corresponde ao conjunto de teorias e pr ticas relacionadas com as medidas a qual permite estimar o desempenho e o custo do software a compara o de projetos e a fixa o dos crit rios de qualidade a atingir As medidas de um software podem ser as mais variadas a escolha da medida devendo obedecer a determinados crit rios a pertin ncia da medida interpretabilidade o custo da medida percentual reduzido do custo do software utilidade possibilidade de compara o de medidas As medidas de um software podem ser organizadas segundo duas grandes categorias 3 1 Mepmas Dm m cas S o as medidas obtidas mediante a execu o do software como por exemplo os testes as medidas de desempenho em velocidade e ocupa o de mem ria os tra os etc Estas medidas podem assumir um interesse relativamente grande pois elas permitem quantificar fatores que podem implicar em retorno econ mico ou que representem informa es sobre a corre o do programa por outro lado estas medidas s podem ser obtidas num momento relativamente tardio do ciclo de desenvolvimento de um software ou seja a partir da etapa de testes 3 2 Mepmpas est ticas S o aquelas obtidas a partir do documento fonte do software sem a necessidade de execu o do software Dentre a
124. em ser organizadas em outras classes as quais ser o definidas a seguir e m tricas da produtividade baseadas na sa da do processo de desenvolvimento do software com o objetivo de avaliar o pr prio processo e m tricas da qualidade que permitem indicar o n vel de resposta do software s exig ncias expl citas e impl citas do cliente e m tricas t cnicas nas quais encaixam se aspectos como funcionalidade modularidade manutenibilidade etc Sob uma outra tica poss vel definir uma nova classifica o das medi es e m tricas orientadas ao tamanho baseadas nas medi es diretas da Engenharia de Software e m tricas orientadas fun o que oferecem medidas indiretas e m tricas orientadas s pessoas as quais d o indica es sobre a forma como as pessoas desenvolvem os programas de computador n CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 7 3 M tricas oRIentanas ao tamanxo Esta classe abrange todas as poss veis medidas obtidas diretamente do software Um exemplo de tal classe de medidas mostrado na tabela a seguir Como pode ser verificado na tabela desta figura cada projeto caracterizado por um conjunto de par metros que permite obter diversas informa es tanto sobre a produtividade do processo quanto sobre a qualidade do software obtido Pode se ent o definir algumas grandezas tais como Produtividade KLOC pessoa m s Qualidade erros K
125. enha uma garantia do funcionamento do software nos moldes estabelecidos pela especifica o dos requisitos Finalmente devem ser registrados neste documento a lista de documentos relacionados ao software a ser desenvolvido Plano de Software por exemplo e uma se o de Ap ndices onde podem ser apresentadas informa es mais detalhadas sobre a especifica o do software descri o detalhada de algoritmos diagramas gr ficos etc Um outro aspecto interessante n o apresentado na figura refere se a quando um software ter caracter sticas de interatividade com usu rios Neste caso interessante que um Manual de Usu rio em vers o preliminar seja elaborado o qual vai conduzir a duas consequ ncias positivas for ar o analista a enxergar o software do ponto de vista do usu rio permitir ao cliente uma avalia o do que ser o software nesta etapa de desenvolvimento 7 AN LISE ESTRUTURADA A An lise Estruturada ou SSA para Structured System Analysis foi desenvolvida em meados dos anos 70 por Gane Sarson e De Marco A t cnica SSA baseada na utiliza o de uma linguagem gr fica para construir modelos de um sistema incorporando 5 9 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA tamb m conceitos relacionados s estruturas de dados Os elementos b sicos da An lise Estruturada s o o Diagrama de Fluxo de Dados o Dicion rio de Dados as Especifica es de Processos e as T cnica
126. ente simples A maior parte dos sistemas de software constru dos atualmente j vem dotada de um utilit rio de desativa o ou desinstala o que retira automaticamente todos os componentes do sistema e as refer ncias a estes componentes do sistema computacional Outro aspecto importante da desativa o dos sistemas s o as informa es que este manipulava ou gerava Esta normalmente dever o ser armazenadas em m dia espec fica para posterior adapta o utiliza o num novo sistema 819 CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA Y PROJELO ARQUNELURAL Yi O Mopezo Do Sistema Um importante resultado da especifica o de requisitos e do projeto de um sistema computacional a sua organiza o em termos de subsistemas e dos relacionamentos entre estes A forma mais usual de representar esta organiza o sem d vida os modelos baseados em linguagem gr fica Invariavelmente a utiliza o de diagramas em blocos destacando os principais subsistemas e como estes est o relacionados bastante aceita nos projetos de sistemas em geral incluindo os sistemas computacionais A figura 3 4 ilustra tal mecanismo atrav s do exemplo de projeto arquitetural de um sistema de controle de tr fego a reo O objetivo aqui n o descrever o funcionamento de um tal sistema mas mostrar como se pode representar os diferentes componentes deste e como estes relacionam se As setas ligando
127. ento de projeto gt Listagem di Documentos de teste Configura o v lida Software liberado no mercado Figura 8 5 A revis o de configura o Neste caso praticamente imposs vel haver um controle da parte do desenvolvedor sobre os erros encontrados Estes normalmente s o registrados pelo pr prio usu rio e encaminhados ao desenvolvedor na forma de um relat rio escrito Atualmente muitas empresas fazem uso deste processo encaminhando ou disponibilizando via Internet vers es beta de seus softwares sendo que as informa es sobre erros encontrados podem ser fornecidas ao desenvolvedor atrav s de correio eletr nico ou atrav s do acesso a p ginas Web especialmente desenvolvidas 8 12 CAP 8 TESTE DE SOFTWARE PROF Vit rio BRUNO MAZZOLA Infelizmente por m muitos usu rios de vers es beta n o t m a preocupa o de contribuir efetivamente para a valida o apenas fazendo uso do software para seu pr prio interesse 7 teste De SISTEMA Como j foi mencionado o software definido apenas como um elemento de um sistemas que pode envolver hardware elementos humanos e outros Por esta raz o uma vez validado ele ser incorporado aos demais elementos Um problema comumente encontrado neste tipo de teste o cl ssico apontar o dedo onde o respons vel pelo desenvolvimento de um elemento do sistema tenta livrar se da responsabilidade do erro acusando outro elemento do sistema como causa
128. entos de teste uma vez que esta a ltima etapa de revis o da especifica o do projeto e da codifica o A realiza o de forma cuidadosa e criteriosa dos procedimentos associados ao teste de um software assume uma import ncia cada vez maior dado o impacto sobre o funcionamento e o custo que este componente tem assumido nos ltimos anos Por esta raz o o esfor o despendido para realizar a etapa de teste pode chegar a 40 do esfor o total empregado no desenvolvimento do software No caso de programas que ser o utilizados em sistemas cr ticos aqueles sistemas dos quais dependem vidas humanas como controle de v o e a supervis o de reatores nucleares a atividade de teste pode custar de 3 a 5 vezes o valor gasto nas demais atividades de desenvolvimento do software O objetivo deste cap tulo apresentar de forma breve os principais conceitos e t cnicas relacionados ao teste de software 2 FUNDAMENTOS DO Teste DE SOFTWARE 2 1 OsJerivos Os objetivos do teste de software podem ser expressos de forma mais clara pela observa o das tr s regras definidas por Myers e A atividade de teste o processo de executar um programa com a inten o de descobrir um erro e Um bom caso de teste aquele que apresenta uma elevada probabilidade de revelar um erro ainda n o descoberto e Um teste bem sucedido aquele que revela um erro ainda n o descoberto As tr s regras expressam o objetivo primordial do teste que
129. equisitos do software e do uso de m todos de desenvolvimento que explorem esta formaliza o 222 Robustez A robustez a capacidade do sistema funcionar mesmo em condi es anormais um fator diferente da corre o Um sistema pode ser correto sem ser robusto ou seja O seu funcionamento vai ocorrer somente em determinadas condi es O aspecto mais importante relacionado robustez a obten o de um n vel de funcionamento do sistema que suporte mesmo situa es que n o foram previstas na especifica o dos requisitos Na pior das hip teses importante garantir que o software n o vai provocar consequ ncias catastr ficas em situa es anormais Resultados esperados s o que em tais situa es o software apresente comportamentos tais como a sinaliza o da situa o anormal a termina o ordenada a continuidade do funcionamento correto mesmo de maneira degradada etc Na literatura estas caracter sticas podem ser associadas tamb m ao conceito de confiabilidade 22 3 Extensibilidade a facilidade com a qual se pode introduzir modifica es nos produtos de software Todo software considerado em princ pio flex vel e portanto pass vel de modifica es No entanto este fator nem sempre muito bem entendido principalmente quando se trata de pequenos programas Por outro lado para softwares de grande porte este fator atinge uma import ncia consider vel e pode ser atingido a partir de do
130. er bastante interessante principalmente em sistemas interativos Al m disso a posse de um Manual de Usu rio mesmo em est gio preliminar permite ao cliente uma revis o dos requisitos de interface pelo menos ainda num est gio bastante prematuro do desenvolvimento de software Desta forma algumas decep es resultante de uma m defini o de alguns aspectos do software podem ser evitadas 3 PROCESSOS DE COMUNICA O O desenvolvimento de um software na maior parte dos casos motivado pelas necessidades de um cliente que deseje automatizar um sistema existente ou obter um novo sistema completamente automatizado O software por m desenvolvido por um desenvolvedor ou por uma equipe de desenvolvedores Uma vez desenvolvido o software ser provavelmente utilizado por usu rios finais os quais n o s o necessariamente os clientes que originaram o sistema Isto significa que de fato existem tr s partes envolvidas no processo de desenvolvimento de um produto de software o cliente o desenvolvedor e os usu rios Para que o processo de desenvolvimento seja conduzido com sucesso necess rio que os desejos do cliente e as expectativas dos eventuais usu rios finais do sistema sejam precisamente transmitidos ao desenvolvedor 5 3 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA Este processo de transmiss o de requisitos do cliente e dos usu rios ao desenvolvedor invariavelmente apresenta rela
131. es a serem executadas pelo sistema de requisitos de desempenho das interfaces a serem oferecidas das restri es de projeto e das estruturas de informa o que ser o processadas por cada um dos elementos constituintes do sistema software hardware pessoal etc Neste trabalho importante que se estabele a da forma mais precisa poss vel as fun es a serem realizadas Por exemplo no caso do sistema de controle de um rob n o suficiente dizer que ele deve reagir com rapidez se a bandeja de ferramentas estiver vazia na realidade importante especificar cuidadosamente os diferentes aspectos deste requisito o que vai indicar a bandeja vazia para o rob Os limites de tempo relacionados com a rea o de que forma deve ser esta rea o Uma vez identificados e analizadas todas as fun es requisitos e restri es passa se fase de aloca o onde o objetivo atribuir aos diferentes elementos que constituem o sistema as fun es analizadas anteriormente Nesta tarefa comum estabelecer alternativas de aloca o para posterior defini o Consideremos por exemplo um sistema de tratamento gr fico onde uma das fun es principais a transforma o tridimensional de imagens Deste exemplo poss vel imaginar algumas op es de solu es existentes OD todas as transforma es ser o resolvidas por software Qas transforma es mais simples redimensionamento e transla o ser
132. es relacionadas ao desenvolvimento de cada subsistema definido no projeto Cada subsistema ter suas fun es bem definidas e suas especificidades quanto s compet ncias necess rias ao seu desenvolvimento No caso de um subsistema de software um processo de desenvolvimento caracterizado pelas etapas cl ssicas de desenvolvimento ser iniciado Em raras situa es o desenvolvimento de um sistema imp e a constru o a partir do zero de todos os subsistemas que o comp em O mais comum que alguns subsistemas sejam adquiridos e incorporados ao sistema Embora seja o caso mais comum nem sempre f cil integrar subsistemas de prateleira a um sistema em muitos casos s o necess rias modifica es no sentido de adaptar o subsistema adquirido s necessidades do sistema a ser desenvolvido Al m disso nem sempre poss vel prever a disponibilidade de um subsistema de prateleira no momento em que ele necess rio A Engenharia de Hardware para efeito de defini o de um dado sistema consiste no trabalho de sele o dos componentes que v o compor o hardware do sistema e que ser o capazes de assumir as fun es atribu das a este elemento Atualmente o trabalho de sele o dos componentes de hardware mais simples do que o de software sendo facilitado pelos seguintes fatores os componentes s o montados como blocos de constru o individuais as interfaces entre os componentes s o padronizadas existem numerosas
133. esa de Normaliza o AFNOR a qualidade definida como a capacidade de um produto ou servi o de satisfazer s necessidades dos seus usu rios Esta defini o de certa forma coerente com as metas da Engenharia de Software particularmente quando algumas defini es s o apresentadas E o caso das defini es de Verifica o e Valida o introduzidas por Boehm que associa a estas defini es as seguintes quest es Verifica o Ser que o produto foi constru do corretamente Valida o Ser que este o produto que o cliente solicitou O problema que surge quando se reflete em termos de qualidade a dificuldade em se quantificar este fator 2 1 Fatores De QuaLiDane Externos e Internos Algumas das propriedades que poder amos apontar de imediato s o a corre o a facilidade de uso o desempenho a legibilidade etc Na verdade analizando estas propriedades poss vel organiz las em dois grupos importantes de fatores que vamos denominar fatores externos e internos Os fatores de qualidade externos s o aqueles que podem ser detectados principalmente pelo cliente ou eventuais usu rios A partir da observa o destes fatores o 2 2 CAP 2 QUALIDADE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA cliente pode concluir sobre a qualidade do software do seu ponto de vista Enquadram se nesta classe fatores tais como o desempenho a facilidade de uso a corre o a confiabilidade a
134. eta o inadequada de aspectos da especifica o de projeto restri es ou complexidades caracter sticas da linguagem de programa o adotada e etc As restri es impostas por uma dada linguagem de programa o ou o conhecimento incompleto das suas potencialidades pode conduzir a racioc nios e conseq entes projetos relativamente limitados 7 2 CAP 7 LINGUAGENS DE PROGRAMA O PROF Vit rio BRUNO MAZZOLA 3 CARACTER STICAS DAS LMGUAGENS DE PROGRAMA O Como j foi mencionado as linguagens de programa o funcionam no processo de desenvolvimento de software como o agente de formaliza o das representa es de projeto perante o sistema computacional As caracter sticas de uma linguagem de programa o podem exercer um impacto significativo no processo de codifica o segundo diferentes ngulos os quais ser o abordados nos par grafos que seguem 3 1 Caracter sticas PsicoL Gicas Sob a tica psicol gica aspectos tais como a facilidade de uso simplicidade de aprendizagem confiabilidade e baixa frequ ncia de erros s o caracter sticas que devem ser apresentadas pelas linguagens de programa o estes fatores podem causar impacto significativo no processo de desenvolvimento de um software considerando a codifica o como uma atividade intrinsecamente humana As caracter sticas de ordem psicol gica s o apresentadas abaixo 3 1 1 Uniformidade Esta caracter stica est relaci
135. etalhada a qual pode incluir exemplos A figura 2 3 apresenta um exemplo de estrutura de uma tarefa chave para a Area Chave de Planejamento do Projeto de Software 5 4 Utiza o no monero CMM O objetivo fundamental do estabelecimento deste modelo fornecer par metros para e de um lado que as institui es que pretendam contratar fornecedores de software possam avaliar as capacidades destes fornecedores e por outro lado para que as empresas de desenvolvimento de software possam identificar quais os procedimentos a serem implementados ou institucionalizados no mbito da organiza o de modo a aumentar a capabilidade do seu processo de software 211 CAP 2 QUALIDADE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA reas Chave e Gerenciamento de requisitos Repet vel 2 e Planejamento do processo de desenvolvimento e Acompanhamento do projeto e Gerenciamento de subcontrata o e Garantia de qualidade e Gerenciamento de configura o e nfase ao processo na organiza o e Defini o do processo na organiza o e Programa de treinamento e Gerenciamento integrado e Engenharia de software e Coordena o intergrupo e Atividades de revis o e Gerenciamento quantitativo do processo e Preven o de falhas Otimizado 5 Gerenciamento de mudan a de tecnologia e Gerenciamento de mudan a do processo Definido 3 Tabela 2 1 reas Chave por n vel de maturidade Objetivos realiza o processo
136. etas de melhorias no processo de desenvolvimento sejam estabelecidas como forma de incrementar estes dois importantes fatores da Engenharia de Software Particularmente no que diz respeito qualidade poss vel com uma avalia o quantitativa deste par metro promover se pequenos ajustes no processo de desenvolvimento como forma de eliminar ou reduzir as causas de problemas que afetam de forma significativa o projeto de software No que diz respeito aos desenvolvedores a obten o de medidas podem auxiliar a responder com precis o uma s rie de perguntas que estes elementos se fazem a cada projeto e que tipos de requisitos s o os mais pass veis de mudan as e quais m dulos do sistema s o os mais propensos a erros e quanto de teste deve ser planejado para cada m dulo ui CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA e quantos erros de tipos espec ficos pode se esperar quando o teste se iniciar 7 2 Menmas De Sortware Na rea de engenharia a medi o tem sido um aspecto de grande import ncia sendo que poder amos desfilar uma fila intermin vel de grandezas as quais sofrem este tipo de tratamento dimens es f sicas peso ou massa temperatura tens es e correntes el trica etc No mundo dos computadores alguns par metros s o quantificados como forma de expressar as potencialidades de determinadas m quinas tais como a capacidade de um processador de executar um ce
137. etos com seus atributos e opera es e organizados segundo hierarquias e associa es com os diagramas de outras classes 4 1 1 Objetos e classes Todos os objetos tem uma identidade e s o distingu veis Eles s o instancias de classes de objetos que descrevem grupos de objetos com similaridade nas propriedades atributos comportamento opera es rela es com os outros objetos e sem ntica A nota o gr fica para representar objetos classes e suas rela es composta de dois tipos de diagramas mostrados na figura 9 1 e um diagrama de classe que representa classes de objetos e tem a fun o de ser um esquema um padr o ou um template para os dados e um diagrama de inst ncia utilizado para representar inst ncias de classes e tem o objetivo de descrever como um conjunto particular de objetos se relaciona com outro O atributo colocado na segunda parte da caixa ver figura 9 2 Cada nome de atributo pode ser seguido por detalhes opcionais tais como tipo precedido por e valor default precedido de Identificadores expl citos de objeto n o s o necess rios no modelo objeto pois cada objeto j tem a sua propria identidade a partir de seus valores 9 5 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA Pessoa Pessoa Pessoa Clara M rcio Pessoa Classe Objetos Figura 9 1 Ilustra o de Classes e Objetos Pessoa
138. fetuadas importante considerar algumas regras valida o de todas as entradas de dados simplicidade e padroniza o no formato da entrada no caso de entradas envolvendo m ltiplos dados estabelecer um indicador de final de entrada ENTER ponto final etc e entradas de dados interativas devem ser rotuladas indicando se eventuais par metros op es e valores default rotula o de relat rio de sa da e projeto 6 CODIFICA O e EFICI NCIA Embora os fatores determinantes da efici ncia na execu o de software possam ser determinados fundamentalmente por aspectos de hardware como o processador utilizado e o espa o de mem ria dispon vel a codifica o pode ter uma participa o mesmo modesta na redu o do tempo de processamento de um programa ou na menor ocupa o de espa o na mem ria De modo geral existem basicamente tr s regras a serem observadas no tocante efici ncia 7 9 CAP 7 LINGUAGENS DE PROGRAMA O PROF Vit rio BRUNO MAZZOLA a efici ncia um requisito de desempenho e deve portanto ser contemplada desde a etapa de an lise e defini o dos requisitos a efici ncia pode ser melhorada com um bom projeto a efici ncia e a simplicidade do c digo devem ser requisitos bem equilibrados em hip tese alguma deve se sacrificar a clareza e a legibilidade do c digo em nome da efici ncia A codifica o pode ser encaminhada de modo a obter efici nc
139. ficar a consist ncia 5 1 2 Modelo funcional Para construir o modelo funcional necess rio seguir os seguintes passos identificar valores de entrada e sa da construir um DFD mostrando depend ncias funcionais descrever fun es identificar restri es i e depend ncias funcionais entre objetos especificar um crit rio de otimiza o 5 1 3 Acrescentando as opera es O estilo de an lise apresentado n o da nfase nas opera es entretanto necess rio distinguir os v rios tipos de opera es durante a fase de an lise opera es a partir do modelo objeto de eventos de a es e atividades no diagrama de estados de fun es DFD 6 PROJETO ORIENTADO A OBJETOS O projeto orientado a objetos se divide em projeto do sistema e projeto do objeto descritos sucintamente a seguir 6 1 ProJeto Do Sistema O projeto do sistema consiste em tomar decis es de alto n vel sobre o como o problema ser resolvido e a solu o constru da O projeto de sistemas inclui decis es sobre a arquitetura do sistema i e sobre a organiza o do sistema em subsistemas a aloca o de subsistemas a componentes de hardware ou de software e sobre a pol tica e a estrat gia que formam o quadro no qual o projeto detalhada poder ser desenvolvido O projetista do sistema deve tomar as seguintes decis es 9 17 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA organizar o sistema
140. ftware de Orienta o a Objetos Estudando a bibliografia da rea observa se que cada autor apresenta a sua vis o do que entende por esta abordagem A v o alguns conceitos e a orienta o a objeto pode ser vista como a abordagem de modelagem e desenvolvimento que facilita a constru o de sistemas complexos a partir de componentes individuais e o desenvolvimento orientado a objetos a t cnica de constru o de software na forma de uma cole o estruturada de implementa es de tipos abstratos de dados e desenvolvimento de sistemas orientado a objetos um estilo de desenvolvimento de aplica es onde a encapsula o potencial e real de processos e dados reconhecida num estagio inicial de desenvolvimento e num alto n vel de abstra o com vistas a construir de forma econ mica o que imita o mundo real mais fielmente e a orienta o a objetos uma forma de organizar o software como uma cole o de objetos discretos que incorporam estrutura de dados e comportamento Visando a que cada leitor passe a ter a sua pr pria defini o do que significa Orienta o a Objetos vamos apresentar aqui os principais conceitos relacionados a esta tecnologia 2 ORIENTA O A OBJETOS CONCENOS 2 Caracter sticas De OBJeros Um objeto algo distingu vel que cont m atributos ou propriedades e possui um comportamento Cada objeto tem uma identidade e distingu vel de outro mesmo que seus atributos sejam id nticos
141. funcionando de forma adequada Por outro lado uma m quina de comando num rico s ir realizar corretamente o seu trabalho se o software de pilotagem tiver sido adequadamente concebido Entender o papel da Engenharia de Sistemas Computacionais constatar que um sistema algo mais do que a simples uni o de seus diversos elementos Num sistema de grande porte existe um conjunto de propriedades que s o verificados somente a partir do momento em que os diferentes elementos do mesmo s o integrados S o as chamadas Propriedades Emergentes Alguns exemplos destas propriedades s o e o peso global do sistema um exemplo de propriedade que pode ser previamente determinada a partir de propriedades individuais dos componentes e a confiabilidade do sistema que est fortemente dependente da confiabilidade de cada elemento 3 3 CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF Vit rio BRUNO MAZZOLA e a facilidade de uso que vai estar relacionada aos diferentes elementos do sistema como o hardware o software mas tamb m aos usu rios do mesmo 2 3 Sistemas e SuBsistemas Pode se observar ainda que elementos de um determinado sistema podem operar de forma aut noma constituindo se num sistema independente No entanto ao serem incorporados ao sistema suas funcionalidades v o estar dependendo de outros elementos deste Uma c mera de v deo por exemplo pode ser vista como um sistema independente Por outro lado
142. gado atada 4 1 2 Principais Aspectos da Engenharia de Sistemas 4 1 de An lise de Sistemas ssa od cenicas ass a a E a 4 5 4 Arquitetura do SISTEMA assar aque a Era saE aquela Eus 7 ODegdad da solado reta Ea ea 4 6 5 Especifica o e Revis o isesusszassnialzadiqas ressaualzanntusa Puneafssnslh tool pais niabso Bu auea Tas 4 8 Car turo 5 An lise De Requisitos Ta 5 6 jo 0 ei o a PR RR RR RENDER NPR RR 5 1 2 As Atividades da An lise de Requisitos 5 1 3 Processos de COMUNICA O za asrtasas a asas idas as ls Tr ele nadas a 5 2 4 Principios de An li Semirara e a E paras 5 3 5 Prototipa o de Software esseeeeeesseeererrrntreserrrrnrrntttseernnrrnntesserrnnnrnnn ennet 5 6 6 Especifica o dos Requisitos de Software e rerena 5 7 7 An lise Estruturada eeeeeeooeeeeneeeneeerererrrrtrestrrrtrnnnrrsrerrerrnnnreseerrenrnnne tenet 5 8 8 Tecnicas de An lise reer manaira e medir ep r sd pra t 5 14 Car tuLo 6 PROJeto De SOFWARE Sort q Go O glipo o D 6 72 o FONE SEU SD PR a OR RREO RR RR E EREE 6 1 O Processo de Projeto Sex asnicnimensisrera pisar te nato r SO N dad 6 1 Aspectos Fundamentais do Projeto nn rsseraana 6 2 Classes de Projeto radio sa do RA RER NS AA ERES AO Pra CRS E e a 6 5 DOCUMENTA O sra asa is 6 9 Projeto de Interfaces Homem M quina s aos 6 11 Car tuLo 7 LMGUAGeNs De PROGRAMA O
143. gt y i levanta fone timeout Timetout a o beep baixo Tom Discagem a o som discagem fone no gancho d gito N d gito N n mero Mensagem Gravada fone no gancho TT a inv lido a o toca mensagem n mero v lido No Tom Ocupado fone no gancho Conectando a o tenta conex o Tom de Bloqueado bloqueado a o tom bloqueado roteado fone no gancho Chamando a o toca campainha mensagem tocada resposta correspondente k fonenogancho Conectado correspondente desliga linha desconectada fone no gancho Desconectado Figura 9 14 Diagrama de estados de uma linha telef nica 4 2 2 Opera es Uma descri o do comportamento de um objeto deve especificar o que o objeto faz em resposta a eventos Opera es associadas estados ou transi es s o realizadas em resposta aos estados correspondentes ou a eventos Uma atividade uma opera o que leva tempo para se completar Ela associada a um estado A nota o do A dentro de um caixa de estado indica que a atividade A inicia na entrada no estado e para na sa da Uma a o uma opera o instant neo e associada a um evento Uma a o representa uma opera o cujo a dura o pequena comparada com a resolu o do diagrama de estados A es podem tamb m representar opera es de controle interno A nota o para uma a o numa trans
144. i o um seguido do nome da a o ap s o evento que a causa A figura 9 15 representa os diagramas de estados com opera es 4 2 3 Diagramas de estado aninhados Os diagramas de estado podem ser estruturados para permitir descri es concisas de sistemas complexos Atrav s de uma generaliza o poss vel expandir num n vel mais baixo adicionando detalhes uma atividade descrita num n vel superior E poss vel organizar estados e eventos em hierarquias com heran a de estrutura e comportamento comuns como no caso da heran a de atributos e opera es em classes de objetos Estado 1 evento1 atributos condi o a o Estado 2 a o atividade 1 Eas Figura 9 15 Diagrama de estados generaliza o RE of pu CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF Vit rio BRUNO MAZZOLA A agrega o permite quebrar um estado em componentes ortogonais com intera o limitada entre eles da mesma foram como se tem uma hierarquia de agrega o de objetos a agrega o equivalente concorr ncia de estados estados concorrentes correspondem geralmente a agrega es de objetos Uma atividade num estado pode ser expandida como um diagrama de estados de baixo n vel cada estado representando um degrau da atividade Atividades aninhadas s o diagramas de estados uma vez com transi es de entrada e sa da de forma similar a subrotinas Um diagrama de estados aninhado uma form
145. ia segundo diferentes vis es as quais ser o discutidas a seguir 6 1 Erici ncia De C DIGO Este aspecto est relacionado diretamente efici ncia dos algoritmos que ser o implementados nos componentes do software Embora estes sejam especificados na fase de projeto detalhado o estilo de codifica o pode trazer uma contribui o importante particularmente com a observa o das seguintes regras express es aritm ticas e l gicas devem ser simplificadas como uma tarefa que anteceda a codifica o malhas aninhadas devem ser cuidadosamente analisadas para verificar a possibilidade de moves instru es para fora delas quando poss vel privilegiar o uso de estruturas de dados simples evitando estruturas do tipo vetores multidimensionais ponteiros e listas complexas adotar opera es aritm ticas r pidas evitar a mistura de diferentes tipos de dados mesmo que a linguagem utilizada permita isto e utilizar express es booleanas e aritm tica de n meros inteiros sempre que poss vel 6 2 Erici ncia De Mem ria Este item refere se ao fato do programa ocupar o menor espa o poss vel na mem ria da m quina Embora no que se refere a grandes computadores e mesmo em computadores pessoais em alguns casos a efici ncia de mem ria n o seja uma quest o fundamental a preocupa o verdadeira no caso de sistemas dedicados N o existem propriamente regras expl citas para se atingir a efici ncia de mem
146. iadas formas permite obter sem d vida programas mais simples Um programador que domine efetivamente as constru es b sicas da programa o estruturada n o encontra grandes dificuldades para combin las durante a atividade de s ntese de um dado procedimento A mesma observa o pode ser feita para as atividades de an lise 4 4 2 O pseudoc digo Esta nota o pode ser aplicada tanto para o projeto arquitetural quanto para o projeto detalhado e a qualquer n vel de abstra o do projeto O projetista representa os aspectos estruturais e de comportamento utilizando uma linguagem de s ntese com express es de sua l ngua Ingl s Portugu s etc e estruturada atrav s de constru es tais como IF THEN ELSE WHILE DO REPEAT UNTIL END etc Esta pol tica permite uma representa o e uma an lise dos fluxos de controle que determinam o comportamento dos componentes do software bastante adequadas posterior deriva o do c digo de implementa o 6 8 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA O uso do pesudoc digo pode suportar o desenvolvimento do projeto segundo uma pol tica top down ou bottom up No caso do desenvolvimento top down uma frase definida num dado n vel de projeto substitu da por seq ncias de frases que representam o refinamento da frase original O pseudoc digo apesar de n o apresentar uma vis o gr fica da estrutura do software ou de seu comportament
147. ica de comportamento que pode eventualmente ser representada por um pseudoc digo Exemplos de fluxogramas b sicos para a composi o de fluxogramas mais complexos s o apresentados na figura 6 3 Uma t cnica gr fica tamb m definida para a representa o de comportamento de componentes de um software o diagrama de Nassi Schneiderman Esta t cnica baseada na representa o atrav s de caixas das estruturas de controle cl ssicas De forma similar aos fluxogramas estruturados os diagramas de Nassi Schneiderman s o baseados na exist ncia de blocos b sicos representando estruturas elementares de controle que ser o combinados de modo a compor a representa o total do software ou do componente de software projetado 6 9 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA ENQUANTO P REPITA S SE P ENT O S1 FA A S ATE P SEN O S2 Figura 6 3 Exemplos de blocos b sicos para fluxogramas estruturados A figura 6 4 apresenta alguns exemplos de blocos b sicos definidos nesta t cnica A representa o de comportamento obtida a partir do encaixe das estruturas b sicas formando uma caixa como mostra o exemplo da figura 6 5 E SEQU NCIA IF THEN ELSE DO WHILE REPEAT UNTIL Figura 6 4 Exemplos de blocos b sicos dos diagramas de Nassi Schneiderman 5 DOCUMENTA O A figura 6 6 apresenta uma proposta de estrutura para o documento de
148. idade a flexibilidade e a possibilidade de reutiliza o Um produto de software ou software como vamos chamar ao longo do curso por outro lado sistematicamente destinado ao uso por pessoas outras que os seus programadores Os eventuais usu rios podem ainda ter forma es e experi ncias diferentes o que significa que uma grande preocupa o no que diz respeito ao desenvolvimento do produto deve ser a sua interface refor ada com uma documenta o rica em informa es para que todos os recursos oferecidos possam ser explorados de forma eficiente Ainda os produtos de software devem passar normalmente por uma exaustiva bateria de testes dado que os usu rios n o estar o interessados e nem ter o capacidade de detectar e corrigir os eventuais erros de execu o Resumindo um programa desenvolvido para resolver um dado problema e um produto de software destinado resolu o do mesmo problema s o duas coisas totalmente diferentes E bvio que o esfor o e o conseq ente custo associado ao desenvolvimento de um produto ser o muito superiores Dentro desta tica importante para melhor caracterizar o significado de software importante levantar algumas particularidades do software quando comparadas a outros produtos considerando que o software um elemento l gico e n o f sico como a maioria dos produtos e o software concebido e desenvolvido como resultado de um trabalho de engenharia e n o manufaturado no
149. ificado de cada estado do sistema que informa es dever o ser oferecidas pela interface em cada estado 6 2 3 Par metros de Projeto Durante o desenvolvimento de uma interface existem alguns par metros vis veis pelo usu rio que devem fazer parte das preocupa es do projetista o tempo de resposta um par metro que se mal definido ou omitido num projeto pode conduzir a resultados frustantes a despeito do cuidado com o qual tenham sido tratados outros fatores o tempo de resposta a comandos do usu rio n o tem de ser necessariamente o mais curto poss vel em muitas aplica es pode ser interessante se ter um tempo de resposta mai elevado sem que o usu rio venha a se aborrecer de esperar de forma a permitir que o usu rio reflita sobre as opera es que est realizando o tempo de resposta deve ser projetado observando dois aspectos a extens o o espa o de tempo entre um comando do usu rio e a resposta do software e a variabilidade que se refere ao desvio de tempo de resposta do tempo de resposta m dio de todas as fun es do sistema a ajuda ao usu rio um outro par metro importante uma vez que muito comum a ocorr ncia de d vidas durante a utiliza o de um software na maioria dos softwares dois tipos de facilidades de ajuda podem ser definidas a ajuda integrada que projetada juntamente com o software e que permite que o usu rio obtenha respostas rapidamente sobre t picos relativos a o
150. ilhar similaridades entre as classes apesar de preservar suas diferen as Generaliza o uma rela o do tipo um entre uma classe e uma ou mais vers es refinadas A classe que est sendo refinada uma superclasse e a classe refinada uma subclasse Por exemplo m quina de comando n merico uma superclasse de torno fresadora Atributos e opera es comuns a um grupo de subclasses s o reagrupados na superclasse e compartilhado por cada subclasse Diz se que cada subclasse herda as caracter sticas de sua superclasse A nota o para a generaliza o um tri ngulo conectando uma superclasse a suas subclasses conforme visto na figura 9 12 As palavras pr ximas ao tri ngulo no diagrama s o discriminadores i e atributos de um tipo enumera o que indica qual propriedade de um objeto est sendo abstra do por uma rela o de generaliza o particular Os discriminadores est o inerentemente em correspond ncia um a um com as subclasses da generaliza o poss vel rela o de heran a em v rios n veis A heran a em 2 ou 3 n veis at 5 em alguns casos de profundidade aceit vel j a mais de 10 n veis excessiva A generaliza o facilita a modelagem a partir de classes estruturadas e da captura do que similar e do que diferente nas classes A heran a de opera o de grande ajuda durante a implementa o para facilitar a reutiliza o de c digo Utiliza se a generaliza o para se
151. intera es externas ajustar a estrutura de classes para adicionar a heran a realizar o projeto das associa es determinar a representa o do objeto empacotar classes e associa es nos m dulos documentar as decis es de projeto Es OAB Engenharia de Software BIBLIOGRAFIA EDWARD YOURDON Modern Structured Analysis Prentice Hall Inc New York 1989 IAN SOMMERVILLE Software Engineering 2a Edi o Addison Wesley Londres 1985 JAMES RUMBAUGH et al Object Oriented Modeling and Design Ed Prentice Hall New Jersey 1991 PANKAJ JALOTE An Integrated Approach to Software Engineering Springer Verlag New York 1991 RICHARD FAIRLEY Software Engineering Concepts McGraw Hill New York 1985 ROGER S PRESSMAN Engenharia de Software 3 Ed MeGraw Hill Makron Books do Brasil S o Paulo 1995 9 2
152. ios operadores do hardware e do software bancos de dados uma cole o de informa es organizada sistematicamente acessada atrav s do software documenta o manuais formul rios e outros documentos que podem auxiliar no conhecimento do uso e opera o do sistema procedimentos as regras que especificam o uso espec fico de cada elemento do sistema computacional As combina es destes elementos podem ser as mais diversas para permitir a transforma o das informa es Um rob por exemplo um sistema computacional que transforma um arquivo contendo instru es espec ficas num conjunto de movimentos e a es 2 2 Composi o Dos Sistemas Compuxacionais e as PRopRIeDaDes Emergentes importante reconhecer o papel das atividades relacionadas Engenharia de Sistemas Computacionais como determinantes para as tarefas que se desenvolveram com base em seus resultados Embora tenhamos dito que um Sistema Computacional composto de diferentes elementos n o se deve negligenciar o fato de que a integra o destes diferentes elementos uma tarefa longe de ser trivial O fato de se ter elementos concebidos com exemplar n vel de qualidade n o garante que a reuni o destes v originar um sistema excepcional Em tais sistemas as depend ncias de um elemento do sistema com rela o a outros podem se dar em muitos n veis Por exemplo o software s pode automatizar a solu o de um problema se o processador estiver
153. ir um dado desativa o de comandos inadequados ao contexto das a es realizadas num dado momento o que pode evitar que o usu rio gere erros de execu o pela introdu o de um comando inv lido por exemplo invalidar o comando Reduzir Zoom quando a redu o chegou ao seu limite fornecimento de poder de intera o ao usu rio permitindo que ele controle a navaga o aolongo do software eliminando a es de comando e recuperando se de erros sem a necessidade de abandonar o software minimizar o esfor o do usu rio para a entrada de dados evitar que o usu rio tenha de digitar unidades na entrada de grandezas f sicas utilizando uma unidade default modific vel eliminar a necessidade de digita o de 00 quando os valores n o contiverem componentes decimais etc 6 17 Engenharia de Software CAP 7 LINGUAGENS DE PROGRAMA O Pror Vit rio BRUNO MAZZOLA Car tuLo 7 Lm uncens De PROGRAMA O 1 INTRODU O Todas as etapas discutidas at o momento no contexto do curso s o desenvolvidas visando a obten o de um c digo execut vel que ser o elemento central do produto de software Sob esta tica o c digo do programa nada mais do que uma formaliza o numa dada linguagem das id ias analisadas na etapa de engenharia do sistema dos requisitos estabelecidos na etapa de an lise e dos modelos gerados na etapa de projeto de modo a que o sistema computacional alvo possa execut
154. is crit rios importantes a simplicidade de projeto ou seja quanto mais simples e clara a arquitetura do software mais facilmente as modifica es poder o ser realizadas a descentraliza o que implica na maior autonomia dos diferentes componentes de software de modo que a modifica o ou a retirada de um componente n o 2 3 CAP 2 QUALIDADE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA implique numa rea o em cadeia que altere todo o comportamento do sistema podendo inclusive introduzir erros antes inexistentes 2 2 4 Reusabilidade a capacidade dos produtos de software serem reutilizados totalmente ou em parte para novas aplica es A necessidade vem da constata o de que muitos componentes de software obedecem a um padr o comum o que permite ent o que estas similaridades possam ser exploradas para a obten o de solu es para outras classes de problemas Este fator permite principalmente atingir uma grande economia e um n vel de qualidade satisfat rios na produ o de novos softwares dado que menos programa precisa ser escrito o que significa menos esfor o e menor risco de ocorr ncia de erros Isto significa de fato que a reusabilidade pode influir em outros fatores de qualidade importantes tais como a corre o e a robustez 2 2 5 Compatibilidade A compatibilidade corresponde facilidade com a qual produtos de software podem ser combinados com outros Este um fator relativa
155. ise de Requisitos Desenvolvimento do Software que a fase que tem como ponto de partida os documentos produzidos na fase anterior particularmente o Plano do Software e a Especifica o de Requisitos do Software com base nestes documentos inicia se a etapa de Projeto do Software onde ser o descritos aspectos relacionados ao funcionamento do software como a sua arquitetura e as estruturas de dados ap s avaliada esta defini o inicia se a etapa de Projeto Detalhado onde os aspectos algor tmicos e comportamentais do software s o definidos finalmente a etapa de codifica o encaminhada seja com base no uso de uma linguagem de programa o cl ssica ou com o aux lio de uma ferramenta CASE o resultado desta etapa sendo a listagem dos programas fonte do software em desenvolvimento Verifica o Entrega e Manuten o a ltima fase do processo a qual envolve as atividades de teste do software preparando o para a entrega uma vez entregue inicia se ao longo de toda a vida til do software a etapa de manuten o a qual permitir manter o software em funcionamento a partir da corre o de novos erros que tenham sido detectados com o software em funcionamento da introdu o ou melhorias de fun es do software da adapta o do software para novas plataformas de hardware existentes Por raz es bvias os diferentes subsistemas definidos na etapa de projeto s o desenvolvidos em paralelo No caso de ocorr n
156. istema a segunda vers o apresentada a mais adequada uma vez que ela por um lado mais abrangente e por outro limitante em alguns aspectos A forma como est estabelecido o objetivo do sistema est mais compat vel com as necessidades do ambiente e d uma maior abertura ado o de t cnicas mais evolu das de preven o de inc ndio e intrus o Por outro lado o fato de estabelecer como requisitos a garantia de continuidade das atividades realizadas no escrit rio elimina algumas solu es como o uso de alarme interno ou irrigadores contra inc ndio 3 2 O PROJETO DO sistema Os principais passos envolvidos no projeto de um sistema computacional est o esquematizados na figura 3 3 e ser o descritos nos par grafos que seguem Particionamento dos Requisitos Uma vez estabelecidos os requisitos do sistema na etapa anterior o objetivo deste primeiro passo de projeto particion los segundo algum crit rio l gico A escolha do crit rio de particionamento importante pois deste vai depender as diferentes categorias de requisitos que ser o criadas 38 8 CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA bre iy Particionamento a A dos Requisitos Defini o das Interfaces k e Identifica o Especifica o A dos das Subsistemas Funcionalidades ra Aloca o de Requisitos Figura 3 3 Passos a serem conduzidos no projeto de um sistema computacional
157. istir um grande n mero de motores e inversores operando pode ser determinante para decidir que tipos de protocolos e meios de transmiss o dever o ser empregados devido alta incid ncia de fontes de interfer ncia que podem causar erros de comunica o Um outro aspecto a ser considerado o conjunto de requisitos originado no pr prio ambiente Os exemplos deste aspecto s o os mais diversos mas pode se citar normas de qualidade ou seguran a de produtos requisitos de interface numa dada plataforma requisitos de veda o para um sistema computacional que ir operar num ambiente mido ou sujeito a poeira Por todas estas raz es fundamental que um sistema seja visto sempre como um componente de um sistema maior o estudo aprofundado das caracter sticas mais importantes relativas ao ambiente e dos requisitos impostos por este sendo uma tarefa essencial 2 5 A Aouisi o De Sistemas No desenvolvimento de sistemas principalmente daqueles mais complexos comum que determinados componentes sejam adquiridos em lugar de serem completamente desenvolvidos pela equipe ou empresa envolvida no projeto Em alguns casos o pr prio sistema pode ser completamente adquirido num fabricante espec fico e em outros partes do sistema ser o obtidas de um mesmo ou de diferentes fornecedores Por outro lado pode haver sistemas onde todos os componentes podem ser completamente desenvolvidos pela equipe O processo de decis o sobre a compra
158. jeto 3 2 2 Efici ncia do compilador Esta caracter stica contempla os requisitos de tempo de resposta e concis o exig ncia de pouco espa o de mem ria que podem caracterizar determinados projetos A maioria dos compiladores de linguagens de alto n vel apresenta o inconveniente de gera o de c digo ineficiente 3 2 3 Portabilidade Este aspecto est relacionado ao fato do c digo fonte poder migrar de ambiente para ambiente com pouca ou nenhuma altera o Por ambiente pode se entender o processador o compilador o sistema operacional ou diferentes pacotes de software 3 2 4 Ambiente de Desenvolvimento Um aspecto fundamental sem d vida a disponibilidade de ferramentas de desenvolvimento para a linguagem considerada Neste caso deve ser avaliada a disponibilidade de outras ferramentas que as de tradu o principalmente ferramentas de aux lio depura o edi o de c digo fonte bibliotecas de subrotinas para uma ampla gama de aplica es interfaces gr ficas por exemplo 3 2 5 Manutenibilidade Outro item de import ncia a facilidade em alterar o c digo fonte para efeito de manuten o Esta etapa em muitos casos negligenciada nos projetos de desenvolvimento de software s poder ser conduzida eficientemente a partir de uma completa compreens o do software Embora a exist ncia de documenta o relativa ao desenvolvimento do software seja de fundamental import ncia a clareza do c digo fo
159. l de desenvolvimento de software Entretanto esta simplicidade nem sempre facilmente obtida pois determinadas unidades exigem a exist ncia de drivers ou stubs mais sofisticados para que a atividade de teste seja eficaz 8 7 CAP 8 TESTE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 5 teste De INTEGRA O O teste de integra o realizado no sentido de assegurar que uma vez que as unidades foram testadas e seu bom comportamento foi verificado individualmente estas v o trabalhar de forma cooperativa e harmoniosa quando forem associadas O problema coloc los juntos considerando que cada um deles foi definido com uma interface Quem ainda n o tentou ligar um plug de tr s pinos numa tomada com dois furos Os erros mais comuns de integra o s o perdas de dados atrav s das interfaces efeitos inesperados da combina o de duas ou mais fun es estruturas de dados globais apresentando problemas imprecis es individualmente aceit veis podem gerar imprecis es absurdas etc 5 1 Sistem tica DO teste De Integra o A id ia b sica por tr s do teste de integra o a constru o passo a passo do programa associando suas unidades e testando esta associa o at que se atinja a totalidade do programa projetado Driver Interface Estrutura de dados locais M dulo Condi es de limite e Caminhos independentes Caminho de tratamento de erros
160. los da forma mais precisa e eficaz s o sem d vida um primeiro passo para a sua solu o edi CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA Especifica o Projeto Listagem de Requisitos Programa Funcionando g Plano de Testes Figura 1 2 Componentes do software Em primeiro lugar preciso estar ciente tamb m de que n o existe uma abordagem m gica que seja a melhor para a solu o destes problemas mas uma combina o de m todos que sejam abrangentes a todas as etapas do desenvolvimento de um software Al m disto importante e desej vel que estes m todos sejam suportados por um conjunto de ferramentas que permita automatizar o desenrolar destas etapas juntamente com uma defini o clara de crit rios de qualidade e produtividade de software S o estes aspectos que caracterizam de maneira mais influente a disciplina de Engenharia de Software Na literatura pode se encontrar diversas defini es da Engenharia de Software O estabelecimento e uso de s lidos princ pios de engenharia para que se possa obter economicamente um software que seja confi vel e que funcione eficientemente em m quinas reais NAU 69 A aplica o pr tica do conhecimento cient fico para o projeto e a constru o de programas computacionais e a documenta o necess ria sua opera o e manuten o Boehm 76 Abordagem sistem tica para o desenvolvimento a
161. m para cada classe com comportamento din mico importante ele mostra o modelo de atividade para um sistema completo Cada maquina de estados se executa de forma concorrente e pode mudar de estado independentemente Os diagramas de estado para as v rias classes combinam num modelo din mico nico atrav s de eventos compartilhados Um evento algo que ocorre num instante de tempo e que n o tem dura o Um evento pode preceder ou seguir outro evento ou pode n o ter rela o entre eventos neste caso s o ditos concorrentes Cada evento uma ocorr ncia nica entretanto poss vel reagrupa los em classes de eventos e dar a cada uma delas um nome que indica uma estrutura e um comportamento comuns Alguns eventos s o simples sinais mas muito 04 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA outros tem atributos indicando a informa o que eles transportam O tempo no qual o evento ocorre um atributo impl cito de todos os eventos Um evento transporta a informa o de um objeto a outro os valores de dados transportados por um evento s o seus atributos Os eventos incluem as condi es de erro e as ocorr ncias normais Um cen rio uma sequ ncia de eventos que ocorre durante uma execu o particular de um sistema Ele pode incluir todos os eventos do sistema ou apenas eventos gerados por certos objetos no sistema A sequ ncia de eventos e os objetos que trocam eventos podem ser mostr
162. ma es prop e um caminho para decompor sistematicamente um problema de modo a obter de modo eficiente os diferentes m dulos do software a construir Segundo este princ pio os m dulos devem ser decompostos de modo que as informa es os procedimentos e dados contidas em cada m dulo sejam inacess veis aos m dulos que n o tenham necessidade destas informa es Ao realizar a decomposi o segundo este princ pio o projetista proporciona um grau relativamente alto de independ ncia entre os m dulos o que altamente desej vel num tal projeto Os benef cios da ado o deste princ pio v o aparecer no momento em que modifica es dever o ser encaminhadas a n vel da implementa o por exemplo por consequ ncia de uma atividade de teste do software Gra as oculta o de informa o erros introduzidos como resultado de alguma modifica o num dado m dulo n o ser o propagados a outros m dulos do software Y CLASSES De PROJETO Olhando para os diversos aspectos apresentados na se o anterior pode se verificar que de fato a etapa de projeto de software caracterizada por um conjunto de projetos que desenrolam se paralelamente Nos itens abaixo ser o discutidos estes diferentes projetos Yi O Proseto MopuLar O princ pio da modularidade sem d vida um dos mais difundidos e adotados em qualquer abordagem de desenvolvimento de software conhecida A raz o para isto reside nos benef cios da aplica
163. mente importante dado que um produto de software constru do e adquirido para trabalhar convivendo com outros softwares A impossibilidade de intera o com outros produtos pode ser sem d vida uma caracter stica que resultar na n o escolha do software ou no abandono de sua utiliza o Os contra exemplos de compatibilidade infelizmente s o maiores que os exemplos mas podemos citar nesta classe principalmente a defini o de formatos de arquivos padronizados ASCII PostScript a padroniza o de estruturas de dados a padroniza o de interfaces homem m quina sistema do Macintosh ambiente Windows etc 22 6 Efici ncia A efici ncia est relacionada com a utiliza o racional dos recursos de hardware e de sistema operacional da plataforma onde o software ser instalado Recursos tais como mem ria processador e co processador mem ria cache recursos gr ficos bibliotecas por exemplo primitivas de sistema operacional devem ser explorados de forma adequada em espa o e tempo 22 7 Portabilidade A portabilidade consiste na capacidade de um software em ser instalado para diversos ambientes de software e hardware Esta nem sempre uma caracter stica facilmente atingida devido principalmente s diversidades existentes nas diferentes plataformas em termos de processador composi o dos perif ricos sistema operacional etc Alguns softwares por outro lado s o constru dos em diversas ver
164. mentos e a es com o mouse O uso do teclado num tal sistema restringe se digita o de nomes de arquivos e poucos par metros de configura o Esta evolu o tem sido uma consequ ncia por um lado da evolu o do hardware dos computadores e por outro lado da necessidade em eliminar o terror tecnol gico criado gra as exist ncia de interfaces de dif cil aprendizado complexas no uso e totalmente frustantes em boa parte dos casos 6 1 Os Fatores xumanos Isto faz com que o projeto das interfaces homem m quina deixe de ser visto como mais uma componente do projeto do software como um todo mas que passe a ser considerada uma atividade onde uma s rie de fatores t cnicos e principalmente humanos sejam levados em conta de modo a que o usu rio possa explorar completamente e da forma mais amig vel poss vel as potencialidades do software O projetista de interfaces homem m quina deve conhecer alguns conceitos que ser o fundamentais para o encaminhamento de suas atividades o mecanismo da percep o humana particularmente com rela o aos sentidos de vis o audi o e de tato exprimem a capacidade do ser humano em adquirir armazenar e utilizar as informa es na maior parte das opera es realizadas num computador o usu rio faz uso dos olhos e do c rebro para o processamento das informa es sendo capaz de diferenciar os diferentes tipos de informa o segundo diversos par metros visuais a cor a forma
165. mo forma de automatizar um conjunto de tarefas que v m sendo realizadas de forma inadequada ou ineficiente ou utilizando equipamentos obsoletos ou realizados artesanalmente Sendo assim uma an lise do conjunto destas tarefas primordial ao projeto da interface O objetivo desta an lise viabilizar um mapeamento da interface n o necessariamente id ntico mas pr ximo do conjunto de tarefas que vem sendo realizado pelos profissionais envolvidos na opera o do sistema e que ser o os usu rios finais do software O processo de an lise das tarefas normalmente conduzido segundo uma abordagem por refinamentos sucessivos O projetista identifica as principais tarefas executadas no contexto da aplica o sendo que cada tarefa pode ser eventualmente refinada em duas ou mais subtarefas A partir desta identifica o e refinamento das tarefas o projeto da interface pode ser encaminhado observando se os seguintes passos iniciais estabelecimento dos objetivos de cada tarefa defini o da sequ ncia de a es necess rias para cada tarefa especificar como as a es de cada tarefa estar o acess veis a n vel de interface indicar o aspecto visual da interface para cada acesso a uma a o da sequ ncia especificada estado do sistema definir os mecanismos dispon veis para que o usu rio possa alterar o estado do sistema especificar o efeito de cada mecanismo de controle no estado do sistema indicar o sign
166. n es l gica de execu o interfaces etc 4 3 Fase pe Manmen o A fase de manuten o que se inicia a partir da entrega do software caracterizada pela realiza o de altera es de naturezas as mais diversas seja para corrigir erros residuais da fase anterior para incluir novas fun es exigidas pelo cliente ou para adaptar o software a novas configura es de hardware Sendo assim pode se caracterizar esta fase pelas seguintes atividades e a Corre o ou Manuten o Corretiva a qual consiste da atividade de corre o de erros observados durante a opera o do sistema e a Adapta o ou Manuten o Adaptativa a qual realiza altera es no software para que ele possa ser executado sobre um novo ambiente CPU arquitetura novos dispositivos de hardware novo sistema operacional etc e o Melhoramento Funcional ou Manuten o Perfectiva onde s o realizadas altera es para melhorar alguns aspectos do software como por exemplo o seu desempenho a sua interface a introdu o de novas fun es etc A manuten o do software envolve normalmente etapas de an lise do sistema existente entendimento do c digo e dos documentos associados teste das mudan as teste das partes j existentes o que a torna uma etapa complexa e de alto custo Al m disso considerando a atual situa o industrial foi criado mais recentemente o conceito de Engenharia Reversa onde atrav s do uso das t cnicas e
167. ncionais organizar por ordem de prioridade os programas selecionados registrando os custos levantados no procedimento anterior estimar os custos para realizar a reengenharia dos programas selecionados e estimar os custos de manuten o do programa ap s realizada a reengenharia realizar uma an lise comparativa de custos para cada programa calcular o tempo necess rio para o retorno de investimento da reengenharia e levar em considera o algumas quest es importantes que resultam da reengenharia como a melhor confiabilidade do sistema melhor desempenho e melhores interfaces obter a aprova o da empresa para realizar a reengenharia de um programa com base nos resultados obtidos desta experi ncia desenvolver uma estrat gia de reengenharia dos demais programas 6 PLANEJAMENTO ORGANIZACIONAL Existe uma grande diversidade no que diz respeito aos modos de organiza o das equipes de desenvolvimento de software A escolha da forma como a equipe de desenvolvimento vai ser organizada um dos pontos que deve ser definido nesta etapa Considerando que um processo de desenvolvimento de software vai ocupar uma equipe de n pessoas com uma dura o de k anos poss vel comentar algumas op es organizativas OD n indiv duos s o alocados a m diferentes tarefas com pequeno grau de intera o sendo que a coordena o da equipe fica a cargo do gerente de projeto n indiv duos s o alocados a m diferentes tarefa
168. ndo que para cada projeto em desenvolvimento este pode ser instanciado Um processo de desenvolvimento bem definido deve conter padr es procedimentos para o desenvolvimento das atividades envolvidas mecanismos de valida o e crit rios de avalia o A capabilidade de uma empresa no n vel 3 caracterizada pela padroniza o e consist ncia uma vez que as pol ticas de gerenciamento e as pr ticas da Engenharia de Software s o aplicadas de forma efetiva e repetida 5 2 4 N vel Gerencano No n vel gerenciado realizada a coleta de medidas do processo e do produto obtido o que vai permitir um controle sobre a produtividade do processo e a qualidade do produto E definida uma base de dados para coletar e analisar os dados dispon veis dos projetos de software Medidas consistentes e bem definidas s o ent o uma caracter stica das organiza es situadas neste n vel as quais estabelecem uma refer ncia para a avalia o dos processos de desenvolvimento e dos produtos Os processos de desenvolvimento exercem um alto controle sobre os produtos obtidos as varia es de desempenho do processo podem ser separadas das varia es ocasionais ru dos principalmente no contexto de linhas de produ o definidas Os riscos relacionados ao aprendizado de novas tecnologias ou sobre um novo dom nio de aplica o s o conhecidos e gerenciados cuidadosamente A capabilidade de uma organiza o situada este n vel caracterizad
169. ni o de subsistema introduzida anteriormente Sistema de Automa o da F brica Sistema de Informa es Sistema de Estoques Sistema de Manufatura Sistema de C lula Transporte de Flex vel de Material Manufatura M quina de Controlador Comando Rob L gico Num rico Program vel Figura 3 1 Rela o hier rquica entre sistemas computacionais E per CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA Por esta raz o o ambiente de um sistema deve ser cuidadosamente estudado nesta etapa de concep o A import ncia do entendimento completo do ambiente de um sistema justificada pelos fatores seguintes e em grande parte das vezes o sistema concebido para provocar altera es no ambiente sendo assim a compreens o dos principais aspectos de funcionamento do ambiente ser o fundamentais para especificar de que forma o sistema deve agir para provocar as altera es de forma precisa exemplos de tais sistemas s o um sistema de ilumina o um sistema de aquecimento ou refrigera o de ambiente e mesmo quando a fun o do sistema n o est relacionada a altera es de seu ambiente importante se conhecer o quanto o ambiente pode influenciar no funcionamento do sistema por exemplo numa rede de computadores a ser instalada numa unidade fabrica o de uma empresa o fato de naquela unidade ex
170. nt o o levantamento do impacto que os problemas associados ao risco ter o sobre o projeto e sobre o produto o que permitir priorizar os riscos Pode se destacar tr s fatores que influenciam no impacto de um determinado risco a sua natureza o seu escopo e o per odo da sua ocorr ncia A natureza do risco permite indicar os problemas prov veis se ele ocorrer por exemplo um risco t cnico como uma mal defini o de interface entre o software e o hardware do cliente levar certamente a problemas de teste e integra o O seu escopo permite indicar de um lado qual a gravidade dos problemas que ser o originados e qual a parcela do projeto que ser atingida O per odo de ocorr ncia de um risco permite uma reflex o sobre quando ele poder ocorrer e por quanto tempo Estes tr s fatores definir o a import ncia do risco para efeito de prioriza o um fator de risco de elevado impacto pode ser pouco considerado a n vel do gerenciamento de projeto se a sua probabilidade de ocorr ncia for baixa Por outro lado fatores de risco com alto peso de impacto e com probabilidade de ocorr ncia de moderada a alta e fatores de risco com baixo peso de impacto com elevada probabilidade de ocorr ncia n o devem ser desconsiderados devendo ser processados por todas atividades de an lise de risco dig CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 2 3 Avalia o Dos Riscos O objetivo da atividade de a
171. nte vai ser fator determinante para o sucesso das tarefas de manuten o ETA CAP 7 LINGUAGENS DE PROGRAMA O PROF Vit rio BRUNO MAZZOLA 3 3 Caracter sticas t cnicas As duas classes de caracter sticas apresentadas anteriormente s o de certo modo conseq ncia da forma como as linguagens de programa o foram concebidas tanto do ponto de vista sint tico como sem ntico A seguir ser o apresentadas as principais caracter sticas t cnicas das linguagens de programa o as quais exercem forte impacto na qualidade do software e nas condi es sob as quais este desenvolvido 3 3 1 Suporte a tipos de dados Quanto mais poderosos s o os programas atuais mais complexas s o as estruturas de dados que estes manipulam Nas linguagens de programa o atuais o suporte representa o dos dados caracterizado por diferentes categorias de dados desde estruturas extremamente simples at estruturas com alto grau de complexidade A seguir s o enumeradas algumas destas categorias tipos num ricos inteiros complexos reais bit etc tipos enumerados valores definidos pelos usu rios cores formas etc cadeias de caracteres strings tipos booleanos verdadeiro falso vetores uni ou multidimensionais listas filas pilhas registros heterog neos Na maior parte dos casos a manipula o l gica e aritm tica de dados controlada por mecanismos de verifica o de
172. nterface O teste de interface o primeiro e o mais importante teste a ser aplicado sobre uma unidade de software Ele deve ser realizado em primeiro lugar pois qualquer anomalia observada durante a realiza o deste teste p e em d vida os resultados obtidos nos demais testes sobre a mesma unidade Durante a realiza o deste teste os seguintes aspectos devem ser observados e coer ncia em termos de n meros atributos e sistemas de unidades entre argumentos de um m dulo e os par metros de entrada e coer ncia em termos de n meros atributos e sistemas de unidades entre argumentos passados aos m dulos chamados e os par metros de entrada e verifica o sobre a consist ncia dos argumentos e a ordem de passagem destes nas fun es embutidas e exist ncia de refer ncias a par metros n o associados ao ponto de entrada atual altera o de argumentos de entrada sa da e consist ncia de vari veis globais ao longo dos m dulos passagem de restri es sobre argumentos No caso de unidades que envolvam tratamento de entradas sa das todas as opera es envolvendo tratamento de arquivos ou programa o de dispositivos perif ricos devem ser cuidadosamente ou exaustivamente verificadas 4 1 2 O teste de estruturas de dados Com rela o as estruturas de dados devem ser verificadas n o apenas aquelas que ser o utilizadas exclusivamente no contexto da unidade mas tamb m aquelas definidas em termos globais Pra
173. o uma t cnica bastante interessante pela sua facilidade de uso e pela sua similaridade com algumas das linguagens de implementa o conhecidas como por exemplo Pascal C etc A seguir apresentada uma listagem exemplo de uso do pseudoc digo para o projeto detalhado de um componente de software INICIALIZA tabelas e contadores ABRE arquivos L o primeiro registro de texto ENQUANTO houver registros de texto no arquivo FAZER ENQUANTO houver palavras no registro de texto FAZER L a pr xima palavra PROCURA na tabela de palavras a palavra lida SE a palavra lida encontrada ENT O INCREMENTA o contador de ocorr ncias da palavra lida SEN O INSERE a palavra lida na tabela de palavras INCREMENTA o contador de palavras processadas FIM ENQUANTO FIM ENQUANTO IMPRIME a tabela de palavras e o contador de palavras processadas FECHA arquivos FIM do programa 4 4 3 O uso de nota es gr ficas Outra contribui o importante s atividades de projeto pode ser ado o de nota es gr ficas para representar os procedimentos a serem implementados O fluxograma uma conhecida t cnica para a representa o do fluxo de controle de programas particularmente os programas sequenciais Os fluxogramas estruturados s o aqueles baseados na exist ncia de um conjunto limitado de fluxogramas b sicos que combinados comp em uma representa o de comportamento de um elemento de software O resultado obtido uma representa o gr f
174. o A etapa inicial da fase de an lise consiste no estabelecimento dos requisitos do problema a ser resolvido fornecendo uma vis o conceptual do sistema proposto O dialogo subsequente com o usu rio o conhecimento da rea e a experi ncia adquirida do mundo real s o elementos adicionais que servem de entrada para a an lise A sa da desta fase de an lise um modelo formal que captura os aspectos essenciais do sistema objetos e suas rela es fluxo din mico de controle e transforma o funcional de dados No caso da metodologia OMT obt m se os modelos objeto din mico e funcional 9 16 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA 5 1 Moneo oBseto Para construir o modelo objeto necess rio seguir os seguintes passos identificar objetos e classes preparar um dicion rio de dados identificar associa es incluindo agrega es entre objetos identificar atributos de objetos e liga es organizar e simplificar classes de objetos utilizando heran a verificar os caminhos de acesso iterar e refinar o modelo agrupar as classes em m dulos 5 1 1 Modelo din mico Para construir o modelo din mico necess rio seguir os seguintes passos preparar cen rios de sequ ncias de intera o t picas identificar eventos entre objetos preparar um rastro de eventos para cada cen rio construir um diagrama de estados equiparar eventos entre objetos para veri
175. o big bang onde todos os seus subsistemas s o conectados num passo nico Entretanto por raz es t cnicas e gerenciais a forma mais adequada a integra o incremental dos diferentes subsistemas As principais raz es para ado o desta estrat gia s o 1 Na maior parte dos casos imposs vel sincronizar o fim do desenvolvimento de todos os subsistemas 2 A integra o incremental reduz os custos de identifica o e corre o de erros de integra o Quando um n mero muito grande de subsistemas s o integrados simultaneamente uma falha no sistema pode ser conseq ncia de um ou mais erros presentes nos diferentes subsistemas No caso da integra o incremental a ocorr ncia de uma falha pode ser mais facilmente controlada pois ela ser muito provavelmente conseq ncia de um erro no subsistema mais recentemente integrado No caso de sistemas em que os subsistemas foram constru dos por diferentes fornecedores muito comum ocorrer desentendimentos quando um problema de integra o acontece Os fornecedores tendem a acusar um ao outro como o respons vel do problema detectado Este tipo de ocorr ncia bastante prejudicial ao desenvolvimento do sistema podendo tomar muito tempo para que o problema seja resolvido 3 5 Instala o Do Sistema Esta etapa envolve todas as atividades relacionadas coloca o do sistema em funcionamento no ambiente para o qual ele foi concebido Embora possa parecer um problema
176. o processo de desenvolvimento que vai em geral definir como as etapas relativas ao desenvolvimento do software ser o conduzidas e interrelacionadas para atingir o objetivo do desenvolvimento que a obten o de um produto de software de alta qualidade a um custo relativamente baixo As se es que seguem v o descrever alguns dos modelos conhecidos e utilizados em desenvolvimento de software 3 2 1 O Modelo Queda d gua Este o modelo mais simples de desenvolvimento de software estabelecendo uma ordena o linear no que diz respeito realiza o das diferentes etapas Como mostra a figura 1 3 o ponto de partida do modelo uma etapa de Engenharia de Sistemas onde o objetivo ter uma vis o global do sistema como um todo incluindo hardware software equipamentos e as pessoas envolvidas como forma de definir precisamente o papel do software neste contexto Em seguida a etapa de An lise de Requisitos vai permitir uma clara defini o dos requisitos de software sendo que o resultado ser utilizado como refer ncia para as etapas posteriores de Projeto Codifica o Teste e Manuten o Engenharia de Sistemas An lise de Requisitos Ea Projeto E Codifica o Teste e Integra o Opera o e Manuten o Figura 1 3 Ilustra o do modelo Queda d gua O modelo Queda d gua apresenta caracter sticas interessantes particularmente em raz o da defini o de um ordenamento linear das et
177. o realizadas em hardware e as mais complexas rota o perspectivas etc em software todas as transforma es ser o realizadas por um processador geom trico implementado em hardware A escolha da solu o deve ser baseada num conjunto de crit rios onde entram fatores como custo realizabilidade desempenho padroniza o de interfaces portabilidade etc Nas se es a seguir ser o descritas atividades encaminhadas no contexto da Engenharia de Sistemas Computacionais 3 1 Dermi o Dos Regusros O objetivo das tarefas a serem desenvolvidas nesta etapa identificar os requisitos do Sistema Computacional a ser concebido Considerando que grande parte dos sistemas computacionais s o constru dos sob demanda a forma usual de encaminhar esta etapa caracterizada por um conjunto de reuni es estabelecidas entre a equipe de desenvolvimento do sistema e os clientes ou usu rios Nesta etapa pode se considerar basicamente tr s categorias de requisitos 3 7 CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF Vit rio BRUNO MAZZOLA e os requisitos b sicos que est o associados s fun es a serem desempenhadas pelo sistema neste momento do desenvolvimento estes requisitos s o definidos num n vel de abstra o relativamente elevado uma vez que o detalhamento ser necessariamente realizado numa etapa posterior e as propriedades do sistema que est o relacionadas s propriedades emergentes do
178. o ao projeto dos m dulos pode se ainda apresentar algumas defini es importantes a independ ncia funcional que surge como consegu ncia da aplica o dos princ pios de abstra o e oculta o de informa o segundo alguns pesquisadores da rea a independ ncia funcional pode ser obtida a partir da defini o de m dulos de prop sito nico e evitando se excessivas intera es com outros m dulos a coes o que est fortemente ligada ao princ pio de oculta o e que sugere que um m dulo pode realizar a sua fun o com um m nimo de intera o com os demais m dulos do sistema desej vel que os m dulos num software apresentem um alto grau de coes o o acoplamento que permite exprimir o grau de conex o entre os m dulos os m dulos de um software devem apresentar um baixo coeficiente de acoplamento La O Projeto Dos Dados medida que a etapa de projeto evolui as estruturas de dados v o assumindo um papel mais importante nesta atividade uma vez que estas v o definir a complexidade procedimental do software ou de seus componentes O projeto dos dados nada mais do que a sele o das representa es l gicas dos objetos de dados identificados na etapa de An lise e Especifica o dos Requisitos Como forma de obter resultados satisfat rios no que diz respeito ao projeto dos dados no contexto de um software alguns princ pios podem ser adotados a realiza o de uma an lise sistem tica no
179. o assim o suporte a conceitos como classe heran a encapsulamento e troca de mensagens pode ser um aspecto interessante numa linguagem utilizada na implementa o de um projeto orientado a objetos 3 4 Crr rios De scoLxa De uma Lnauacem De Programa o As caracter sticas apresentadas acima devem ser levadas em conta no momento da escolha de uma linguagem de programa o no contexto de um projeto de software Por outro lado outros crit rios podem auxiliar na decis o entre eles a rea de aplica o para a qual o software est sendo constru do a complexidade computacional e algor tmica do software o ambiente no qual o software vai executar os requisitos de desempenho a complexidade da estrutura de dados o conhecimento da equipe de desenvolvimento a disponibilidade de boas ferramentas de desenvolvimento Y CLASSES DE LINGUAGENS Devido grande diversidade das linguagens de programa o existentes nos dias atuais interessante estabelecer uma classifica o que permita situ las no contexto do desenvolvimento de programas Embora os crit rios de classifica o possam ser os mais diversos adotou se aqui uma tica cronol gica onde as linguagens posicionam se de certo modo em fun o de suas caracter sticas t cnicas 4 1 Lmeuacens e Primeira Gera o Nesta classe de linguagens desenvolvidas nos prim rdios da computa o enquadram se as linguagens em n vel de m quina O c digo
180. o de tal princ pio tanto durante o desenvolvimento quanto ao longo da fase de manuten o do software Durante o projeto os princ pios de abstra o e de oculta o de informa o s o aplicados como forma de obten o dos m dulos que constituem a arquitetura de um 6 6 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA programa A aplica o destes dois princ pios vai se refletir em caracter sticas de opera o do m dulo como o tempo de incorpora o que indica o momento da introdu o do m dulo no c digo fonte do software por exemplo um macro de compila o um subprograma etc o mecanismo de ativa o que indica a forma como o m dulo ser invocado durante a execu o do programa por exemplo por meio de uma refer ncia instru o call ou por interrup o o padr o de controle o qual descreve como o m dulo executado internamente No que diz respeito aos tipos de m dulos que podem ser definidos na arquitetura de um software pode se encontrar basicamente tr s categorias os m dulos sequenciais que s o ativados e sua execu o ocorre sem qualquer interrup o os m dulos incrementais que podem ser interrompidos antes da conclus o do aplicativo e terem sua execu o retomada a partir do ponto de interrup o os m dulos paralelos que executam simultaneamente a outros m dulos em ambientes multiprocessadores concorrentes No que diz respeit
181. o ponto de partida da etapa de projeto do software mas na maioria dos casos grande parte dos sistemas computacionais especificada acomodando alguns detalhes de implementa o O conhecimento de alguns destes detalhes pode auxiliar o analista e em seguida o projetista na defini o de restri es impostas ao software pelo sistema 5 6 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA 5 PROTOLIPA O DE SOFTWARE 5 1 Moriva es e raras na PRrovoriPa o A etapa de An lise de Requisitos engloba um conjunto de atividades de fundamental import ncia para o processo de desenvolvimento de um software e deve ser portanto realizada independentemente da abordagem e t cnica utilizadas Em muitos casos poss vel aplicar se t cnicas de an lise de modo a derivar uma representa o em papel ou em arquivo no caso da utiliza o de uma ferramenta CASE que sirva de refer ncia para o projeto do software Em outras situa es a partir da coleta de requisitos um modelo do software um prot tipo pode ser constru do de modo a permitir uma melhor avalia o por parte do desenvolvedor e do cliente O paradigma da prototipa o tem como ponto de partida uma Solicita o de Proposta encaminhada pelo cliente A partir desta solicita o os seguintes passos s o realizados an lise da solicita o para identificar a necessidade da prototipa o normalmente softwares interativos e ou gr fi
182. o significa que os dados e os eventos fazem parte do dom nio de informa o do software sendo que basicamente tr s pontos de vista podem ser considerados para abordar esta quest o o fluxo da informa o o qual representa a forma pela qual os dados e os eventos se modificam ao longo do sistema o que pode ajudar a determinar quais LB Am CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA s o as transforma es essenciais s quais os itens de informa o s o submetidos o conte do da informa o que permite representar os dados e os eventos que estejam relacionados a um determinado item de informa o sem ntica da informa o a estrutura da informa o a qual permite expressar a forma como itens de dados e ou eventos est o organizados sintaxe da informa o esta informa o pode vir a ser importante para a etapa de projeto e implementa o das estruturas de informa o via software linguagens de programa o 4 2 Mopera em A modelagem um outro aspecto de import ncia no processo de an lise de requisitos de um software uma vez que ela permite uma melhor compreens o das quest es arquiteturais e comportamentais do problema a ser resolvido com o aux lio do software Uma boa modelagem de software deve permitir a representa o da informa o a ser transformada pelo software das fun es ou sub fun es respons veis das transforma es e do comportamento do sistema durante a o
183. onada consist ncia coer ncia da nota o definida para a linguagem a restri es arbitr rias e ao suporte a exce es sint ticas e sem nticas Um exemplo ou contra exemplo significativo desta caracter stica est na linguagem Fortran que utiliza os par nteses para expressar dois aspectos completamente diferentes na linguagem a preced ncia aritm tica e a delimita o de argumentos de subprogramas 3 1 2 Ambig idade Esta uma caracter stica observada pelo programador na manipula o da linguagem Embora o compilador interprete a instru o de um nico modo o leitor programador poder ter diferentes interpreta es para a mesma express o Um caso t pico de problema relacionado a esta caracter stica a preced ncia aritm tica impl cita Por exemplo a express o x x1 x2 x3 pode levar a duas interpreta es por parte do leitor X X1 X2 X3 OU X X1 X2 X3 3 1 3 Concis o Esta uma outra caracter stica psicol gica desej vel nas linguagens de programa o que est relacionada quantidade de informa es orientadas ao c digo que dever o ser recuperadas da mem ria humana Os aspectos que influem nesta caracter stica s o a capacidade de suporte a constru es estruturadas as palavras chave e abrevia es permitidas a diversidade com rela o aos tipos de dados a quantidade de operadores aritm ticos e l gicos entre outros 3 1 4 Localidade A localidade est relacionada ao
184. onente de software m dulos procedimentos fun es etc Esta narrativa deve concentrar se na especifica o da fun o a ser provida pelo componente evitando detalhes algor tmicos A partir desta narrativa com o aux lio de uma t cnica de projeto procedimental obt m se uma descri o estruturada de cada componente A se o V apresenta uma descri o da organiza o dos dados arquivos mantidos em meios de armazenagem dados globais refer ncia cruzada etc Escopo Il Documentos de Refer ncia III Descri o do Projeto 3 1 Descri o dos Dados 3 2 Estrutura de Software 3 3 Interfaces dos Componentes IV Descri o dos M dulos 4 1 Narrativa de Processamento 4 2 Descri o da Interface 4 3 Descri o numa T cnica de Projeto 4 4 Outros V Estrutura de Arquivos e Dados Globais VI Refer ncia Cruzada dos Requisitos VII Procedimentos de Teste VIII Requisitos Especiais IX Observa es X Ap ndices Figura 6 6 Estrutura do documento de Projeto de Software q CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA Na se o VI elaborada uma refer ncia cruzada dos requisitos cujo objetivo determinar que aspectos do projeto desenvolvido est o satisfazendo os requisitos especificados De uma forma mais concreta deve ser feita a indica o de que conjunto de m dulos determinante para a implementa o dos requisitos especificados Na se o VII ap
185. ordagem proposta nesta classe a do ponto por fun o function point a qual baseada em medidas indiretas sobre a complexidade do software A figura 2 2 mostra uma tabela que deve ser preenchida para que se possa obter uma medida sobre a complexidade do software Os valores a serem computados s o os seguintes n mero de entradas do usu rio n mero de sa das do usu rio n mero de consultas do usu rio n mero de arquivos e n mero de interfaces externas Uma vez computados todos os dados um valor de complexidade associado a cada contagem Feito isto obt m se o valor de pontos por fun o utilizando se a seguinte f rmula FP Contagem Total 0 65 0 01 SOMA Fi mid Ss CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF Vit rio BRUNO MAZZOLA Na f rmula acima al m da Contagem Total obtida diretamente da tabela da figura 4 6 Fi para i 1 a 14 corresponde a um conjunto de valores de ajuste de complexidade Fator de pondera o Par metro Contagem Simples M dio Complexo Ent usu rio x 3 4 5 Sa das usu rio O x 4 5 7 Consult usu rio E x 3 4 6 Arquivos o xX 7 10 15 Interfaces ext O xX 5 7 10 Contagem total fannan Figura 4 6 Computa o da m trica ponto por fun o Estes valores s o obtidos a partir de respostas dadas a perguntas feitas a respeito da complexidade do software Os par metros da equa o acima assim como os pesos apresentados na figura 4 6 relativ
186. os aos n veis de complexidade s o obtidos empiricamente Uma vez computados os pontos por fun o podem ser utilizados de forma an loga ao n mero de linhas de c digo LOC para a obten o de medidas de qualidade produtividade e outros atributos Produtividade FP pessoa m s Qualidade erros FP Custo FP Documenta o p gs FP 8 0 PLANO DE SOFTWARE Ao final desta etapa um documento de Plano de Software dever ser gerado o qual dever ser revisto para servir de refer ncia s etapas posteriores Ele vai apresentar as informa es iniciais de custo e cronograma que v o nortear o desenvolvimento do software Ele consiste de um documento relativamente breve o qual encaminhado s diversas pessoas envolvidas no desenvolvimento do software Dentre as informa es a serem contidas neste documento poss vel destacar e o contexto e os recursos necess rios ao gerenciamento do projeto equipe t cnica e ao cliente e a defini o de custos e cronograma que ser o acompanhados para efeito de gerenciamento e d uma vis o global do processo de desenvolvimento do software a todos os envolvidos A figura 4 7 apresenta uma poss vel estrutura para este documento A apresenta o dos custos e cronograma pode diferir dependendo de quem ser o leitor do documento a Pu CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF Vit rio BRUNO MAZZOLA 1 0 Contexto 1 1 Objetivos do projeto 1
187. os m dulos do software de forma exaustiva atrav s de procedimentos de teste de unidade n o h nenhuma garantia de que estes uma vez colocados em conjunto para funcionar n o apresentar o anomalias de comportamento Uma das maiores causas de erros encontrados durante o teste de integra o s o os chamados erros de interface devido principalmente s incompatibilidades de interface entre m dulos que dever o trabalhar de forma cooperativa 3 2 3 O Teste de Valida o Ao final do teste de integra o o software finalmente estruturado na forma de um pacote ou sistema A forma mais simples de defini o do teste de valida o a verifica o de que o software como um todo cumpre corretamente a fun o para a qual ele foi especificado E importante lembrar que no documento de especifica o do software agim CAP 8 TESTE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA quando no in cio da sua concep o s o definidos os chamados crit rios de valida o que servir o de guia para o julgamento de aprova o ou n o do software nesta etapa de testes 3 2 4 O Teste de Sistema Neste tipo de teste s o verificados os aspectos de funcionamento do software integrado aos demais elementos do sistema como o hardware e outros elementos Dependendo do destino do software somente neste momento do teste em que alguns peris de funcionamento do software podem ser efetivamente testados particularmente aqueles aspectos
188. os podem levar diversos anos para serem conclu dos estabelecer os requisitos em termos de hardware um tanto temeroso dadas as frequentes evolu es no hardware e o modelo imp e que todos os requisitos sejam completamente especificados antes do prosseguimento das etapas seguintes em alguns projetos s vezes mais interessante poder especificar completamente somente parte do sistema prosseguir com o desenvolvimento do sistema e s ent o encaminhar os requisitos de outras partes isto n o previsto a n vel do modelo e as primeiras vers es operacionais do software s o obtidas nas etapas mais tardias do processo o que na maioria das vezes inquieta o cliente uma vez que ele quer ter acesso r pido ao seu produto De todo modo pode vir a ser mais interessante a utiliza o deste modelo para o desenvolvimento de um dado sistema do que realizar um desenvolvimento de maneira totalmente an rquica e informal afg CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA 3 2 2 Prototipa o O objetivo da Prototipa o um modelo de processo de desenvolvimento que busca contornar algumas das limita es existentes no modelo Queda d Agua A id ia por tr s deste modelo eliminar a pol tica de congelamento dos requisitos antes do projeto do sistema ou da codifica o Isto feito atrav s da obten o de um prot tipo com base no conhecimento dos requisitos iniciais para o sistema
189. os requisitos de projeto estabelecidos e que apresente boas caracter sticas entre o conjunto apresentado anteriormente sem d vida um grande passo na dire o da obten o de um software de qualidade Entretanto um fator que essencial para a obten o de um c digo claro e que ofere a facilidade de manuten o a boa utiliza o dos mecanismos presentes na linguagem adotada o que vamos rotular aqui por estilo de codifica o Abaixo ser o discutidos os principais fatores determinantes obten o de c digo fonte bem escrito 5 1 R Documenta o De C dico O c digo fonte n o deve ser considerado em nenhuma hip tese como um resultado intermedi rio irrelevante no processo de desenvolvimento de um software Ele se constitui num elemento essencial tanto para atividades de valida o do software como e principalmente para as tarefas de manuten o Desta forma o aspecto de documenta o um aspecto que deve ser bastante considerado na etapa de codifica o Um primeiro passo na documenta o do c digo fonte a escolha dos identificadores de vari veis e procedimentos O uso de siglas ou caracteres para identificar os elementos de um programa uma tend ncia herdada das linguagens de segunda gera o que n o encontra mais lugar nos dias atuais Assim importante que os identificadores escolhidos tenham significado expl cito para a aplica o considerada Outro aspecto bastante considera
190. os tenham sido formalizados ou at que o prot tipo tenha evolu do na dire o de um sistema de produ o 5 2 M topos e Ferramentas De Protorira o O desenvolvimento de um prot tipo uma atividade que deve ser realizada num tempo relativamente curto mas de forma a representar fielmente os requisitos essenciais do software a ser constru do Para conduzir de modo eficiente esta atividade j se disp e de tr s classes de m todos e ferramentas as quais s o apresentadas a seguir as t cnicas de quarta gera o 4GT as quais englobam conjuntos de linguagens para gera o de relat rios e de consulta a bancos de dados e deriva o de aplica es e programas a rea de atua o destas t cnicas Ba CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA atualmente limitada aos sistemas de informa o comerciais embora estejam aparecendo algumas ferramentas orientadas a aplica es de engenharia os componentes de software reus veis os quais permitem a montagem do prot tipo a partir dos blocos de constru o building blocks dos quais n o se conhece necessariamente o seu funcionamento interno mas as suas fun es e interfaces s o dominadas pelo analista o uso desta t cnica s poss vel a partir da constru o ou exist ncia de uma biblioteca de componentes reus veis catalogados para posterior recupera o em alguns casos um software existente pode ser adotado como prot tipo
191. ou o desenvolvimento de um sistema ou de parte dele uma tarefa que requer um esfor o e um tempo consider vel principalmente se o grau de complexidade do mesmo for elevado Uma decis o baseada numa an lise superficial pode conduzir ao fracasso do projeto Normalmente para servir de refer ncia decis o uma especifica o do sistema e um projeto arquitetural devem ser conduzidos Os resultados obtidos nesta tarefa s o importantes pelas seguintes raz es e para que o processo de aquisi o seja encaminhado com sucesso necess ria a exist ncia de uma especifica o e de uma vis o arquitetural do sistema e o custo de aquisi o de um sistema na maioria dos casos menor que do desenvolvimento deste por esta raz o o projeto arquitetural importante como forma de decidir quais subsistemas ser o adquiridos e quais ser o desenvolvidos 3 5 CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA 2 6 R SugcontRata o As situa es em que uma empresa desenvolve completamente todos os componentes de um sistema s o extremamente raras Geralmente a organiza o usu ria vai encomendar o sistema a uma organiza o fornecedora A organiza o fornecedora eventualmente vai terceirizar o desenvolvimento do sistema contratando outras empresas fornecedoras dos diferentes subsistemas A figura 3 2 ilustra este processo Um aspecto interessante deste processo a otimiza o no
192. pa de projeto foi realizada utilizando as boas regras da Engenharia de Software a etapa de codifica o ser consequentemente minimizada em termos de esfor o Projeto Detalhado Codifica o Teste de Unidade ES N N Testes de Testes de Integra o Valida o no Projeto An lise e Revis o dos Projeto da Revis o do Detalhado Especifica o Requisitos Arquitetura Proj Preliminar Codifica o Teste de Unidade a Projeto Codifica o Teste de Unidade Detalhado Planejamento Procedimentos de Teste de Teste N N x Indicador de Progresso Figura 4 3 Exemplo de uma Rede de Tarefas e e CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA An lise e Testes Projeto 30 40 40 50 Codif 15 20 Figura 4 4 Proposta de distribui o dos esfor os de desenvolvimento Nos processos de desenvolvimento em que as etapas de projeto an lise n o s o enfatizadas existe uma raz o porque a etapa de codifica o acaba exigindo maior esfor o que estas etapas atividades de an lise e decis es de projeto acabam sendo efetuadas na etapa de codifica o o que certamente pode corresponder a um custo de desenvolvimento superior ao de um processo onde isto fosse feito segundo uma metodologia mais condizente com o que prega a Engenharia de Software A etapa de testes por sua vez pode representar de 30 a 40 do esfor o total do projeto
193. pequeno investimento inicial An lise de Requisitos Projeto Codifica o Codifica o Teste An lise de Requisitos Figura 1 4 Esquema de evolu o da prototipa o Os prot tipos n o s o sistemas completos e deixam normalmente a desejar em alguns aspectos Um destes aspectos normalmente a interface com o usu rio Os esfor os de desenvolvimento s o concentrados principalmente nos algoritmos que implementem as principais fun es associadas aos requisitos apresentados a interface Lig CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA sendo a este n vel parte sup rflua do desenvolvimento o que permite caracterizar esta etapa por um custo relativamente baixo Por outro lado a experi ncia adquirida no desenvolvimento do prot tipo vai ser de extrema utilidade nas etapas posteriores do desenvolvimento do sistema real permitindo reduzir certamente o seu custo resultando tamb m num sistema melhor concebido 3 2 3 Desenvolvimento Iterativo Este modelo tamb m foi concebido com base numa das limita es do modelo Queda d Agua e combinar as vantagens deste modelo com as do modelo Prototipa o A id ia principal deste modelo ilustrada na figura 1 5 a de que um sistema deve ser desenvolvido de forma incremental sendo que cada incremento vai adicionando ao sistema novas capacidades funcionais at a obten o do sistema final sendo que a cada passo
194. perclasses 9 3 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA 2 7 PoLmoRrismo O polimorfismo significa que uma mesma opera o pode se comportar de forma diferente em classes diferentes Exemplo de polimorfismo a opera o calcular o per metro que diferente para as inst ncias de classe circulo e pol gono ou a opera o mover diferente para janela de computador e pe a de xadrez Uma opera o que tem mais de um m todo que a implementa dita polim rfica Nos sistemas orientados a objetos o suporte seleciona automaticamente o m todo que implementa uma opera o correto a partir do nome da opera o e da classe do objeto no qual esta se operando da mesma forma que no mundo real onde o objeto real tem conhecimento intr nseco do significado da opera o a realizar Essa associa o em tempo de execu o chamada de liga o din mica ou dynamic binding 3 DESENVOLVIMENTO ORIENTADO A OBJETOS O desenvolvimento orientado a objetos diz respeito aos procedimentos de concep o de sistemas a partir dos conceitos b sicos anteriores Ele corresponde s principais fases do ciclo de vida de software an lise projeto e implementa o Existem v rias t cnicas para o desenvolvimento orientado a objetos cujas caracter sticas ser o citadas a seguir 31 omt Ossecr Mopezima Tecunigue A t cnica OMT se distingue pela sua divis o em 4 fases an lise projeto de
195. permite indicar o per odo durante o qual determinada atividade ser realizada o tempo necess rio sendo medido em unidades de tempo consideradas Quando atividades puderem ser realizadas em paralelo os tra os v o ocupar unidades de tempo comuns O cronograma deve explicitar as atividades relevantes do desenvolvimento e os indicadores de progresso associados E importante que os indicadores de progresso sejam representados por resultados concretos por exemplo um documento A disponibilidade de recursos deve tamb m ser representada ao longo do cronograma O impacto da indisponibilidade dos recursos no momento em que eles s o necess rios deve tamb m ser representado se poss vel no cronograma 4 8 CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF Vit rio BRUNO MAZZOLA S eed o Fun o 1 Requisitos Projeto Codifica o Teste Fun o2 Requisitos m Projeto Codifica o Teste Esfor o Total Figura 4 5 Representa o geral de um cronograma de desenvolvimento AQUISI O DE SOFTWARE Embora a Engenharia de Software sugira o desenvolvimento de software em alguns casos pode ser mais interessante adquirir o software do que desenvolv lo Esta uma decis o a qual o gerente de um projeto pode ter de tomar no contexto de um projeto Com rela o aquisi o de software diversas a es podem ser tomadas e adquirir ou licenciar um pacote comercial que atenda s especifica
196. produto precede a data de finaliza o do produto se desenvolvido internamente figa CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA o custo de aquisi o mais o custo de customiza o ser inferior ao custo de desenvolvimento interno o custo de suporte externo contrato de manuten o inferior ao custo do suporte interno 5 ReCNGENHARIA Um outro problema importante a ser tratado pela Engenharia de Software s o os antigos pacotes de software que s o fundamentais realiza o de neg cios de uma empresa e que oferecem grandes dificuldades de manuten o Historicamente a manuten o destes pacotes foi realizada com base em verdadeiros remendos sem nenhuma documenta o resultando muitas vezes em programas ineficientes e com alta taxa de falhas Estes fatores conduziram a uma situa o na qual os custos de manuten o de tais sistemas n o justificam mais os benef cios que tais altera es podem trazer Por outro lado um processo de reengenharia do software pode aparecer como uma alternativa de baixo custo manuten o do software Para isto importante que os seguintes procedimentos sejam encaminhados selecionar os programas que estejam sendo bastante utilizados no momento e que continuar o a ser utilizados nos pr ximos 5 a 10 anos estimar o custo anual de manuten o dos programas selecionados incluindo corre o de erros adapta o e melhorias fu
197. projeto de software O objetivo deste documento apresentar uma descri o completa do software sendo que as se es v o sendo geradas medida que o projetista avan a no seu trabalho de refinamento da representa o do software Na se o apresentado o escopo global do software sendo que grande parte do que vai conter esta se o derivada diretamente do documento de Especifica o de Requisitos obtido na etapa precedente assim como de outros documentos gerados na fase de defini o do software A se o Il apresenta as refer ncias espec ficas documenta o de apoio utilizada A Descri o de Projeto objeto da se o Ill apresenta uma vis o de projeto preliminar Nesta parte do documento apresentada a estrutura do software obtida a partir de diagramas de fluxos de dados ou outras t cnicas de representa o utilizadas durante a etapa de An lise de Requisitos Juntamente com a estrutura do software s o apresentadas as diferentes interfaces de cada componente de software 6 10 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA EE EE N essea t efjs la A s JL Figura 6 5 Exemplo de representa o de comportamento utilizando Nassi Schneiderman Nas se es IV e V s o apresentados os resultados das atividades de refinamento que conduzem aos n veis mais detalhados de projeto Inicialmente apresentada uma narrativa em linguagem natural da opera o de cada comp
198. quando ela est embutida num sistema de seguran a automatizado a maior parte de seus ajustes enquadramento da imagem foco ativa o e desativa o ser o completamente dependentes de outros componentes do sistema de seguran a Isto significa que nos sistemas computacionais comum um dado sistema compor um outro sistema computacional de n vel hier rquico superior Diz se ent o que o sistema considerado um macroelemento ou subsistema do sistema de n vel superior Um exemplo t pico desta situa o aquela dos equipamentos de manufatura como por exemplo os rob s m quinas de comando num rico e controladores l gicos program veis que s o sistemas computacionais e ao mesmo tempo subsistemas de um sistema computacional de n vel hier rquico superior a c lula de manufatura A c lula de manufatura pode ser definida como um sistema computacional uma vez que esta caracterizada por todos os elementos definidos acima Se for feita uma an lise considerando outros n veis hier rquicos poss vel visualizar a c lula como um macroelemento de outro sistema computacional o sistema de manufatura A figura 3 1 ilustra esta rela o entre os diferentes sistemas computacionais descritos 2H Hierarquia e amBiente De um sistema Reconhecido o fato de que um sistema pode ser obtido a partir de outros sistemas como o exemplo ilustrado figura 3 1 surge ent o o conceito de hierarquia de sistemas que vai permitir utilizar a defi
199. que diz respeito aos contatos entre a organiza o do usu rio e as organiza es desenvolvedoras Na realidade o nico contato mantido pela organiza o usu ria com a principal contratante As subcontratantes v o projetar e construir os subsistemas cujos requisitos foram especificados pela principal contratante que exerce o papel de aglutinadora de todas as empresas envolvidas no desenvolvimento 2 7 A Import ncia Do Sortware No desenvolvimento de sistemas computacionais comum a utiliza o de componentes customizados constru dos sob medida e componentes de prateleira Por esta raz o o componente de software assume um papel bastante importante no desenvolvimento do sistema isto porque este que pode assumir a fun o de elo de liga o entre os diferentes componentes permitindo a adequa o do funcionamento dos diferentes componentes de hardware principalmente aqueles de prateleira aos requisitos do sistema Um exemplo deste fato est num dos sistemas computacionais mais utilizados nos dias atuais os microcomputadores da linha PC O PC da IBM quando foi concebido foi totalmente constru do a partir de componentes de hardware dispon veis no mercado Esta decis o foi tomada devido urg ncia em ocupar o espa o do mercado no setor de computadores pessoais Entretanto a f rmula m gica da IBM para fazer com que todos estes elementos funcionassem harmonicamente foi buscada no software no caso o ROM BIOS
200. que diz respeito aos dados a exemplo do que feito com os aspectos funcionais e comportamentais do software identifica o exaustiva das estruturas de dados e das opera es a serem realizadas sobre elas estabelecimento de um dicion rio de dados eventualmente o mesmo definido na etapa de An lise de Requisitos incluindo refinamentos e adiar decis es de baixa prioridade no que diz respeito ao projeto de dados aplica o do princ pio de refinamentos sucessivos 6 7 CAP 6 PROJETO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA limitar a representa o das estruturas de dados aos m dulos que as utilizar o estabelecimento de uma biblioteca de estruturas de dados teis e das opera es a serem aplicadas a elas reusabilidade ado o de uma linguagem de programa o e projeto que suporte tipos abstratos de dados 1 3 O Projeto ArgureruraL O projeto arquitetural visa a obten o de uma estrutura modular de programa dotada de uma representa o dos relacionamentos de controle entre os m dulos Ainda esta atividade permitem efetuar a fus o dos aspectos funcionais com os aspectos informacionais a partir da defini o de interfaces que ir o definir o fluxo de dados atrav s do programa Uma quest o importante no que diz respeito ao projeto arquitetural que ele deve ser encaminhado prioritariamente a outros projetos E importante antes que outras decis es possam ter tomadas que se tenha
201. que ele est realizando e a ajuda add on a qual incorporada ap s a instala o do software e que exige que o usu rio percorra uma lista relativamente longa de t picos para encontrar a resposta sua d vida bvio que o primeiro tipo de ajuda pode tornar a interface mais amig vel Bda CAP 6 PROJETO DE SOFTWARE PROF Vit rio BRUNO MAZZOLA o tratamento de mensagens de erro um outro aspecto com o qual o projetista deve preocupar se a forma como as mensagens s o apresentadas para o usu rio deve ser cuidadosamente estudada em muitos casos as mensagens de erro indicam situa es anormalidades s quais os usu rios n o t m nenhum controle por exemplo mem ria insuficiente para executar uma dada fun o em outros casos elas sinalizam uma manipula o incorreta por parte do usu rio a qual pode ser corrigida por exemplo indica o de um par metro fora dos limites v lidos neste caso a mensagem deve apresentar informa es suficientemente completas e que permitam que o usu rio recupere a origem do erro no caso em que o erro provoque consequ ncias danosas execu o de uma dada tarefa por exemplo adultera o de conte do de um arquivo estas dever o ser explicitadas na mensagem resumindo quanto melhor elaboradas forem as mansagens de erro menor poder ser a frusta o do usu rio quando elas ocorrerem a rotula o de comandos ou de menus e op es corresponde a um outro aspec
202. r ncia dos principais conceitos relativos Engenharia de Software particularmente no que diz respeito ao uso de t cnicas metodologias e ferramentas de desenvolvimento de software 1 2 CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA 2 PRINCIPAIS ASPECTOS DO SOFTWARE 2 1 Sortware permi o e Caracter sticas Pode se definir o software numa forma cl ssica como sendo um conjunto de instru es que quando executadas produzem a fun o e o desempenho desejados estruturas de dados que permitam que as informa es relativas ao problema a resolver sejam manipuladas adequadamente e a documenta o necess ria para um melhor entendimento da sua opera o e uso Entretanto no contexto da Engenharia de Software o software deve ser visto como um produto a ser vendido importante dar esta nfase diferenciando os programas que s o concebidos num contexto mais restrito onde o usu rio ou cliente o pr prio autor No caso destes programas a documenta o associada pequena ou na maior parte das vezes inexistente e a preocupa o com a exist ncia de erros de execu o n o um fator maior considerando que o principal usu rio o pr prio autor do programa este n o ter dificuldades em princ pio na detec o e corre o de um eventual bug Al m do aspecto da corre o outras boas caracter sticas n o s o tamb m objeto de preocupa o como a portabil
203. r atributos de liga o Modelagem de associa o como classe s vezes til modelar uma associa o como classe Cada liga o se torna uma inst ncia da classe 9 8 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA acess vel por Arquivo 7 autoriza o de acesso Figura 9 8 Atributo de link para associa o muitos para muitos trabalha para Pessoa e Empresa nome seguro social NOME chefe ri endere o endere o sal rio fun o Supervisiona empregado taxa desempenho Figura 9 9 Atributos de link para associa o um para v rios pap is A figura 9 10 mostra um exemplo disto Esta op o particularmente til quando liga es podem participar em associa es com outros objetos ou quando liga es s o sujeitas a opera es Papel Um papel ou role uma extremidade de uma associa o Uma associa o bin ria tem dois papeis um em cada extremidade cada um deles podendo ter seu nome Cada papel numa associa o bin ria identifica um objeto ou um conjunto de objetos associado com um objeto na outra extremidade Nomes de papel s o necess rios em associa es entre objetos da mesma classe conforma consta na figura 9 9 Ordenamento Usualmente do lado de uma associa o v rios os objetos n o t m ordem expl cita e podem ser vistos como um conjunto Entretanto s vezes os obje
204. r b v o causar uma transi o para S se o sistema estiver em S ou para S se o sistema estiver em S 8 1 3 Os diagramas de transi o de estado Uma t cnica tamb m interessante o diagrama de transi o de estados Neste diagrama ret ngulos ou c rculos representam os estados de um processo ou sistema A passagem ou transi o de um estado para o outro representada neste diagrama por setas que definem a dire o da transi o Tanto os estados quanto as transi es s o rotuladas os primeiros indicam nomes para os estados os r tulos associados s setas definem os eventos que provocam as transi es de estados assim como as a es resultantes destas transi es A figura 5 12 ilustra um diagrama de transi o de estado para o sistema representado pela tabela de transi es da figura 5 6 ENTRADA CORRENTE ESTADO CORRENTE CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA Figura 5 11 Uma tabela de transi o com entradas limitadas Figura 5 12 Diagrama de Transi o de Estados 8 2 SADt Uma das ferramentas mais difundidas para a realiza o da an lise de requisitos sem d vida o SADT ou Structured Analysis and Design Technique A t cnica SADT vem sendo utilizada h mais de 15 anos por um grande conjunto de organiza es em todo o mundo O SADT foi concebido de modo a apresentar as principais caracter sticas desej veis num modelo orientado An lise e Especifi
205. ra ser conclu do e por que os custos de produ o t m sido t o elevados e por que n o poss vel detectar todos os erros antes que o software seja entregue ao cliente e por que t o dif cil medir o progresso durante o processo de desenvolvimento de software Estas s o algumas das quest es que a Engenharia de Software pode ajudar a resolver Enquanto n o respondemos definitivamente a estas quest es podemos levantar alguns dos problemas que as originam e raramente durante o desenvolvimento de um software dedicado tempo para coletar dados sobre o processo de desenvolvimento em s devido pouca quantidade deste tipo de informa o as tentativas em estimar a dura o custo de produ o de um software t m conduzido a resultados bastante insatisfat rios al m disso a falta destas informa es impede uma avalia o eficiente das t cnicas e metodologias empregadas no desenvolvimento e a insatisfa o do cliente com o sistema conclu do ocorre frequentemente devido principalmente ao fato de que os projetos de desenvolvimento s o baseados em informa es vagas sobre as necessidades e desejos do cliente problema de comunica o entre cliente e fornecedor e a qualidade do software quase sempre suspeita problema resultante da pouca aten o que foi dada historicamente s t cnicas de teste de software at porque o conceito de qualidade de software algo relativamente recente e o software exis
206. rama Brasil Bras lia E de sw aooo Inst ncias f A Pals tem por capital Cidade Portugal Lisboa he i Figura 9 5 Associa o um para um e links Gp CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF Vit rio BRUNO MAZZOLA Projeto Linguagem Diagrama de Classes Pessoa Projeto Linguagem planilha eletr nica J C Cobol Pessoa Diagrama F de q Clara J Inst ncias Projeto Linguagem programa CAD C Figura 9 6 Associa o tern ria e links Classe exatamente um Classe muitos zero ou mais Q Classe opcional zero ou um 1 Classe um ou mais 1 2 4 Classe numericamente especificado Figura 9 7 Nota o para associa es m ltiplas 4 1 3 Liga es e associa es avan adas Atributo de liga o Similarmente ao caso da classe onde um atributo uma propriedade dos objetos desta um atributo de liga o uma propriedade das liga es numa associa o A figura 9 8 apresenta o caso onde permiss o de acesso um atributo da associa o Acess vel por Cada atributo de liga o tem um valor para cada liga o conforme pode ser visto nesta figura ainda E ainda poss vel ter atributos de liga es para associa es v rios a um conforme visto na figura 9 9 e tamb m para liga es ter rias Apesar de poder substituir os atributos de liga o por atributos de objetos da associa o prefer vel mante
207. re 9 15 Projeto Orientado a QObISLOS us sase as rias iotecatio A na sinde Uol UNa EA add dogs iara 9 16 Engenharia de Software CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA Car tuLo 1 EncenxaRIA De SortwarRe Conceros B SICOS 1 INTRODU O Nos anos 40 quando se iniciou a evolu o dos sistemas computadorizados grande parte dos esfor os e consequentes custos era concentrada no desenvolvimento do hardware em raz o principalmente das limita es e dificuldades encontradas na poca A medida que a tecnologia de hardware foi sendo dominada as preocupa es se voltaram no in cio dos anos 50 para o desenvolvimento dos sistemas operacionais onde surgiram ent o as primeiras realiza es destes sistemas assim como das chamadas linguagens de programa o de alto n vel como FORTRAN e COBOL e dos respectivos compiladores A tend ncia da poca foi de poupar cada vez mais o usu rio de um computador de conhecer profundamente as quest es relacionadas ao funcionamento interno da m quina permitindo que este pudesse concentrar seus esfor os na resolu o dos problemas computacionais em lugar de preocupar se com os problemas relacionados ao funcionamento do hardware J no in cio dos anos 60 com o surgimento dos sistemas operacionais com caracter sticas de multiprograma o a efici ncia e utilidade dos sistemas computacionais tiveram um consider vel crescimento para o que con
208. resentada a especifica o dos procedimentos de teste o que poss vel efetuar gra as defini o j estabelecida da estrutura do software e das interfaces Na se o VIII s o apresentadas as restri es e requisitos especiais para o desenvolvimento do software necessidade de overlay gerenciamento de mem ria virtual processamento de alta velocidade interface gr fica espec fica etc As se es IX e X apresentam dados complementares como a descri o de algoritmos procedimentos alternativos dados tabulares Finalmente pode ser encaminhado o desenvolvimento de um Manual de Instala o Opera es Preliminares a ser inclu do como ap ndice ao documento 6 PROJeLO De INTERFACES HOMEM Mm guMA medida que os sistemas computacionais foram evoluindo e conquistando um n mero cada vez maior de usu rios os aspectos de interface com o usu rio passaram a assumir um papel de fundamental import ncia na constru o de softwares Os computadores pessoais que apareceram no final dos anos 70 s o um exemplo t pico desta evolu o Basta olhar a forma como evoluiu a interface de seu sistema operacional do DOS em sua vers o baseada em linguagens de comando passando pela constru o de uma interface gr fica executando sobre o DOS o Windows at chegar nos dias atuais ao Windows 95 um sistema inerentemente gr fico que permite ao usu rio manipular todos os objetos e eventos de seu sistema atrav s de cones e movi
209. resolu o como um todo Com a finalidade de dominar de forma completa os problemas sob an lise um princ pio fundamental a decomposi o do mesmo em partes menores o que denominaremos de particionamento A partir do particionamento de um problema e a partir da an lise de cada parte estabelecida o entendimento fica mais facilitado Desta forma poss vel estabelecer as interfaces de cada parte do problema de modo a que a fun o global do software seja realizada Segundo este princ pio as fun es os aspectos de comportamento e as informa es a serem manipuladas pelo programa poder o ser alocadas s diferentes partes De um ponto de vista gen rico o procedimento b sico de particionamento o estabelecimento de uma estrutura hierarquizada de representa o da fun o ou da CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA informa o dividindo em parti es o elemento superior esta divis o podendo ser efetuada segundo uma abordagem vertical deslocando se verticalmente na hierarquia ou horizontal As figuras 5 1 e 5 2 representam a aplica o sobre um exemplo das abordagens horizontal e vertical respectivamente No caso dos exemplos ilustrativos o particionamento realizado sobre o aspecto funcional do software mas poderia ser aplicado segundo uma ou outra abordagem sobre os aspectos informacionais ou comportamentais Y Concep es essenciais e De ImPLementa o Os requisitos
210. ria mas o par metro fundamental para obter isto a simplicidade de software Al m disso algumas das regras seguidas para obten o da efici ncia de c digo podem resultar igualmente em efici ncia de mem ria O caso t pico para isto a utiliza o de estruturas de dados simples 6 3 Erici ncia De EntraDas Sa das Este outro aspecto importante a ser considerado no momento da codifica o As principais regras a serem seguidas para se atingir este par metro s o minimizar a quantidade de solicita es de E S fazer uso de buffers para reduzir o ac mulo de opera es de comunica o no caso de E S para dispositivos secund rios deve adotar uma organiza o dos dados em blocos e m todos de acesso simples e as E S para terminais e impressoras devem levar em conta caracter sticas dos dispositivos que melhorem sua velocidade e qualidade aclareza da E S deve prevalecer sobre as quest es de efici ncia TO es Engenharia de Software CAP 8 TESTE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA Car tuLo 8 teste De SOFtWARe 1 INTRODU O O desenvolvimento de software utilizando as metodologias t cnicas e ferramentas da Engenharia de Software n o oferece a total garantia de qualidade do produto obtido apesar de melhor la significativamente Por esta raz o uma etapa fundamental na obten o de um alto n vel de qualidade do software a ser produzido aquela onde s o realizados os procedim
211. rit rios de avalia o da qualidade do software a serem verificados uma vez que o software esteja conclu do 2 AS AUIVIDADES DA AN LISE DE REQUISITOS A etapa de An lise de Requisitos caracterizada basicamente pela realiza o de um conjunto de tarefas as quais ser o discutidas nas se es que seguem 21 A An lise Do ProsLema Nesta tarefa inicial o analista estuda os documentos de Especifica o do Sistema e o Plano do Software como forma de entender o posicionamento do software no sistema e revisar o escopo do software utilizado para definir as estimativas de projeto Um elo de comunica o entre o analista e o pessoal da organiza o cliente deve ser estabelecido sendo que o gerente de projetos pode atuar na coordena o dos contatos A meta do 5 2 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA analista neste contexto identificar os principais fatores do problema a ser resolvido pela tica do cliente 2 2 A Avalia o e S ntese Esta segunda tarefa envolve principalmente uma an lise dos fluxos de informa o e a elabora o de todas as fun es de tratamento e os aspectos de comportamento do software Ainda importante que uma defini o de todas as quest es relacionadas interface com o sistema al m de uma especifica o das restri es de projeto Terminada a an lise o analista pode iniciar a s ntese de uma ou mais solu es para o problema Na s ntese das e
212. rograma s o t o espec ficas que mais ningu m incluindo o pr prio autor ir utilizar tal solu o novamente As diversas experi ncias mostram que isto podem ser um grave erro de avalia o pois conduz na maioria dos casos gera o de c digo incompreens vel representando um grande obst culo reutiliza o Algumas provid ncias no desenvolvimento de um software suportam o respeito a este princ pio raciocinar desde o in cio do desenvolvimento em termos de um software p blico isto vai proporcionar uma economia relativamente grande no que diz respeito ao tempo necess rio para a depura o ou modifica o de partes do c digo documentar suficientemente o programa o que vai permitir uma economia em horas de explica o a outras pessoas de como funciona o programa ou como ele deve ser utilizado projetar o software para que ele seja utiliz vel por iniciantes e rotular todas as sa das salvar ou documentar todas as entradas o que pode facilitar o trabalho de interpreta o de resultados obtidos durante a execu o do software La O PRINC PIO DO aBUSO O SoFtWaRe SER UMILIZADO De Maneira mDeypa Este princ pio diz respeito s manipula es incorretas que os usu rios imprimem ao programa seja por desconhecimento do modo correto de utiliza o seja por simples curiosidade Exemplos destas manipula es s o a manipula o de arquivos de entrada de um programa nas mais diversas condi es arquivo
213. rto n mero de instru es por segundo MIPS as capacidades de armazenamento Mbytes a frequ ncia do clock do processador MHz etc No caso particular do software existem diversas raz es para que a realiza o de medi es seja um item de import ncia e quantizar a qualidade do software como produto e avaliar a produtividade dos elementos envolvidos no desenvolvimento do produto e avaliar os benef cios de m todos e ferramentas para o desenvolvimento de software formar uma base de dados para as estimativas e justificar o pleito e aquisi o de novas ferramentas e ou treinamento adicional para membros da equipe de desenvolvimento De forma an loga a outras grandezas do mundo f sico as medi es de software podem ser classificadas em duas categorias principais e as medi es diretas por exemplo o n mero de linhas de c digo LOC produzidas o tamanho de mem ria ocupado a velocidade de execu o o n mero de erros registrados num dado per odo de tempo etc e as medi es indiretas as quais permitem quantizar aspectos como a funcionalidade complexidade efici ncia manutenibilidade etc As medi es diretas tais quais aquelas exemplificadas acima s o de obten o relativamente simples desde que estabelecidas as conven es espec ficas para isto Por outro lado aspectos como funcionalidade complexidade efici ncia etc s o bastante dif ceis a quantizar As medi es de software pod
214. s com m lt n formando equipes informais de desenvolvimento com um respons vel ad hoc de cada equipe sendo que a coordena o entre as equipes da responsabilidade do gerente do projeto n indiv duos s o organizados em k equipes cada equipe sendo alocada para uma ou mais tarefas a organiza o de cada equipe espec fica a ela pr pria a coordena o ficando a cargo da equipe e do gerente do projeto Sem discutir em detalhes os argumentos contr rios ou a favor de cada uma das op es importante dizer que a constitui o em equipes formais de desenvolvimento como sugere a op o mais produtiva trem CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA O principal objetivo da forma o de equipes o desenvolvimento de um conceito de projeto como sendo o resultado de uma reuni o de esfor os A cria o de equipes evita o sentimento de ego programa o que pode atingir as pessoas envolvidas num desenvolvimento transformando o meu programa em nosso programa De um ponto de vista geral pode se estabelecer uma refer ncia no que diz respeito organiza o de uma equipe de desenvolvimento de software sendo que o n mero de equipes e o n mero de membros de cada equipe vai variar em fun o da grandeza do projeto O n cleo de uma equipe vai ser composto dos seguintes elementos um engenheiro s nior ou programador chefe respons vel do planejamento coor
215. s es cada uma delas orientada para execu o num ambiente particular Exemplos disto s o alguns programas da Microsoft como por exemplo o pacote Microsoft Office que existe para plataformas Macintosh e microcomputadores compat veis IBM 2 2 8 Facilidade de uso Este fator certamente um dos mais fortemente detectados pelos usu rios do software Atualmente com o grande desenvolvimento dos ambientes gr ficos como Windows X Windows e o Sistema Macintosh a obten o de softwares de f cil utiliza o tornou se mais frequente A ado o de procedimentos de aux lio em linha help on line sem d vida uma grande contribui o neste sentido Dada a defini o de software feita no pq CAP 2 QUALIDADE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA in cio do curso por m n o se pode deixar de registrar a import ncia de uma documenta o adequada manual de usu rio capaz de orientar o usu rio em sua navega o pelo software considerado 3 A METROLOGIA DA QUALIDADE DO SOFTWARE Apresentados alguns fatores de qualidade de software a dificuldade que se apresenta como medir a qualidade do software Ao contr rio de outras disciplinas de engenharia onde os produtos gerados apresentam caracter sticas f sicas como o peso a altura tens o de entrada toler ncia a erros etc a medida da qualidade do software algo relativamente novo e alguns dos crit rios utilizados s o question veis A possibilidade de estab
216. s de Estrutura o de Bases de Dados Nos par grafos que seguem apresentaremos os principais fatores e nota es que regem a An lise Estruturada ilustrando por meio de exemplos quando necess rio 7 1 Os Diagramas De FLuxos De Danos Em primeira inst ncia um sistema computacional pode ser representado segundo as informa es que ele manipula e o fluxo destas informa es ao longo do sistema A medida que se deslocam ao longo de um software as informa es de entrada v o sofrendo transforma es no sentido da obten o das informa es de sa da Um Diagrama de Fluxo de Dados DFD uma t cnica gr fica de representa o que permite explicitar os fluxos de informa o e as transforma es que s o aplicadas medida que os dados se deslocam da entrada em dire o sa da Um DFD assume o formato de um esquema como o ilustrado na figura 5 4 Num DFD os processos ou atividades de transforma o s o caracterizados por c rculos ou bolhas identificadas por uma express o que descreva precisamente o processo ou o tipo de transforma o realizada sobre os dados O fluxo de dados expresso por setas rotuladas que interligam os processos e que permitem indicar o caminho seguido pelos dados Ret ngulos rotulados v o definir as origens ou destinos dos dados envolvidos no sistema representando os geradores ou consumidores das informa es Os geradores ou consumidores das informa es n o s o considerados objeto de an lise
217. s diretamente no desenvolvimento o que vai consequentemente implicar em maiores atrasos no cronograma 22 2 Mitos do Cliente Mito 4 Uma descri o breve e geral dos requisitos do software o suficiente para iniciar o seu projeto maiores detalhes podem ser definidos posteriormente Realidade 4 Este um dos problemas que podem conduzir um projeto ao fracasso o cliente deve procurar definir o mais precisamente poss vel todos os requisitos importantes para o software fun es desempenho interfaces restri es de projeto e crit rios de valida o s o alguns dos pontos determinantes do sucesso de um projeto Mito 5 Os requisitos de projeto mudam continuamente durante o seu desenvolvimento mas isto n o representa um problema uma vez que o software flex vel e poder suportar facilmente as altera es Realidade 5 verdade que o software flex vel pelo menos mais flex vel do que a maioria dos produtos manufaturados Entretanto n o existe software por mais flex vel que suporte altera es de requisitos significativas com adicional zero em rela o ao custo de desenvolvimento O fator de multiplica o nos custos de desenvolvimento do software devido a altera es nos requisitos cresce em fun o do est gio de evolu o do projeto como mostra a figura 1 1 po CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA 60 100 x CUSTO 1 5 6x
218. s fica o do Pro do plano Desenvolve e verifica Produto do Pr ximo N vel Imple de acei teste menta ta o o Figura 1 7 O modelo espiral Uma caracter stica importante deste modelo o fato de que cada ciclo encerrado por uma atividade de revis o onde todos os produtos do ciclo s o avaliados incluindo o plano para o pr ximo passo ou ciclo Numa aplica o t pica do modelo pode se imaginar a realiza o de um ciclo zero onde se avalie a realizabilidade do projeto o resultado devendo ser a conclus o de que ser poss vel implementar ou n o o projeto de desenvolvimento As alternativas consideradas neste caso s o de muito alto n vel como por 1 12 CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA exemplo se a organiza o deve desenvolver o sistema ela pr pria ou se deve contratar o desenvolvimento junto a uma empresa especializada O modelo se adequa principalmente a sistemas que representem um alto risco de investimento para o cliente Y YIS O GERAL DA ENGENHARIA DE SOFTWARE Analisando os modelos apresentados na se o precedente poss vel observar que apesar de apresentar denomina es s vezes diferentes e de estarem associadas de modo relativamente distinto as etapas apresentadas s o caracterizadas por atividades similares De um modo geral pode se organizar o processo de desenvolvimento de um software a partir
219. s medidas est ticas podemos destacar as medidas de complexidade textual a qual baseada na computa o do n mero de operadores e do n mero de operandos contidos no texto do software a complexidade estrutural a qual se baseia na an lise dos grafos de controle associadas a cada componente do software as medidas baseadas no texto como o tamanho do programa a taxa de linhas de coment rios etc y QUEST ES IMPORTANTES QUALIDADE DE SOFTWARE Uma vez que alguns par metros relacionados qualidade foram detectados na se o 2 2 cabe aqui discutir alguns princ pios que devem fazer parte das preocupa es de uma equipe de desenvolvimento de software 2pm CAP 2 QUALIDADE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA Li O PRINC PIO DO USO O SOFWARE DEVER SER UULIZADO POR OUTROS Este princ pio implica num cuidado em tornar o software acess vel n o apenas para o usu rio imediato mas tamb m para futuros programadores que ir o trabalhar no c digo fonte seja para elimina o de erros seja para introdu o ou aprimoramento de fun es Com base nestes princ pios o programador ou a equipe de programa o dever prover a necess ria flexibilidade e robustez ao programa desde o in cio do desenvolvimento e n o inserir estes aspectos medida que os problemas v o surgindo Um outro ponto importante que muitas vezes um programador julga que determinadas solu es encontradas a n vel de um p
220. s necess rios ao armazenamento do dado 8 2 2 Refinamento de Diagramas De forma similar ao modelo do Diagrama de Fluxo de Dados o n vel de complexidade de um sistema sob an lise pode conduzir a constru o de um conjunto de diagramas SADT onde um diagrama constru do num dado n vel representa um refinamento de um bloco de um diagrama de n vel superior Com exce o do primeiro diagrama criado os demais diagramas correspondem a detalhamentos de um bloco de diagrama de n vel superior o bloco pai o qual pertence ao diagrama pai Os diagramas que representam os detalhamentos de blocos de um dado diagrama s o denominados diagramas filhos A figura 5 15 apresenta um exemplo de refinamento de um bloco de um actigrama No exemplo o bloco A1 que conectado ao sistema pelos fluxos de dados 11 entrada O1 e 02 sa das C1 controle e m mecanismo refinado em tr s blocos no caso A11 A12 e A13 Um aspecto interessante de ser observado o aparecimento al m dos fluxos de dados relativos aos blocos representados no novo actigrama dos fluxos de dados originais do bloco A1 o que permite verificar a coer ncia do refinamento efetuado Como no caso dos DFDs o refinamento dos diagramas n o infinito mas composto de tantos n veis quantos se julguem necess rios para representar precisamente o sistema O processo de refinamento termina quando considera se que o processo pode ser descrito precisamente numa outra linguagem por e
221. s relativos ao seu funcionamento n o s o apresentados por exemplo o que fazer se um erro na ficha de horas m s detectado Isto permite ter uma vis o mais simples do sistema global Caso alguns detalhes sejam considerados importantes o DFD poder ser refinado numa etapa posterior E preciso destacar aqui que um DFD n o um fluxograma Um DFD exprime apenas o fluxo de dados enquanto o fluxograma exprime o fluxo de controle Num DFD quest es relacionadas a procedimentos de execu o devem ser omitidas sempre aspectos como decis es malhas de controle etc n o fazem parte de um DFD O objetivo principal de um DFD expressar quais as transforma es s o aplicadas aos dados sem preocupa o em representar como s o processadas estas transforma es O primeiro passo para a constru o de um DFD para um dado problema a identifica o das principais entradas e sa das Informa es de entrada e sa da de menor import ncia como por exemplo mensagens de erro podem ser ignoradas num primeiro tempo Uma vez identificadas as entradas uma abordagem pode ser partir das entradas e identificar as principais transforma es pelas quais estas passam at atingirem ou transformarem se em as sa das Um outro princ pio seria caminhar no sentido inverso ou seja das sa das em dire o s entradas Os passos a seguir correspondem a algumas sugest es para a constru o de um DFD iniciar a constru o do DFD partin
222. s segundo um movimento de cima para baixo O processo de integra o inicia se no m dulo de controle principal representado na figura 8 3 pelo m dulo M sendo que o caminho de descida pode ser definido de duas formas depth first descida em profundidade ou breadth first descida em largura Na ilustra o da figura 8 3 a descida em depth first englobaria inicialmente todos os m dulos relacionados a um caminho de controle principal A escolha deste caminho depende principalmente das caracter sticas do software em desenvolvimento Supondo que o caminho principal fosse aquele liderado pelo m dulo M a integra o seria feita abrangendo os m dulos M5 Me e Ms S ent o os m dulos mais direita seriam integrados No caso da integra o breadth first todos os m dulos subordinados a um dado n vel seriam integrados primeiro No caso do exemplo a integra o partiria de M e atingiria inicialmente os m dulos M2 Ms e Ma O processo de integra o conduzido considerando 5 passos e o m dulo principal atua como um Driver e os m dulos de n vel superior por o sob teste s o substitu dos por stubs especialmente constru dos M e M M M M M M M Figura 8 3 Integra o Top Down e dependendo do tipo de descida escolhida depth first ou breadth first os stubs podem ir sendo substitu dos gradualmente por m dulos reais j testados
223. s vazios arquivos bin rios arquivos muito grandes etc ou incorre es sint ticas Muitas vezes entradas sintaticamente corretas podem provocar erros de execu o valores fora de faixa erros de overflow divis o por zero etc Um outro problema a tentativa por parte de usu rios de utiliza o de um dado software para uma outra finalidade que n o aquela para a qual o software foi desenvolvido Para levar em conta este princ pio os cuidados que o programador deve ter s o os seguintes garantir que o software ofere a alguma sa da satisfat ria para qualquer tipo de entrada evitar que o programa termine de forma anormal chamar a aten o para entradas alteradas ou sa das incorretas 4 3 O PRINC PIO Da CYOLU O O SOFtRaRE SER MODIFICADO Este outro aspecto de import ncia no desenvolvimento de software o qual est fortemente ligado com o aspecto da facilidade de manuten o ou extensibilidade E fato reconhecido que os softwares dever o sofrer modifica es estas pelas raz es mais diversas seja devido dete o de um erro residual do desenvolvimento seja por novos requisitos surgidos ap s a instala o do software Isto torna evidente a necessidade de desenvolver o projeto e o c digo de modo a facilitar as modifica es necess rias A exist ncia de um c digo bem estruturado e documentado pelo menos 50 do trabalho resolvido 2 6 CAP 2 QUALIDADE DE SOFTWARE PR
224. se um grande problema em problemas menores as solu es s o encontradas com esfor o relativamente menor Isto significa que quanto maior o n mero de m dulos definidos num software menor ser o esfor o necess rio para desenvolv lo uma vez que o esfor o de desenvolvimento de cada m dulo ser menor Por outro lado quanto maior o n mero de m dulos maior ser o esfor o no desenvolvimento das interfaces o que permite concluir que esta regra deve ser utilizada com modera o Finalmente importante distinguir o conceito de modularidade de projeto com o de modularidade de implementa o Nada impede que um software seja projetado sob a tica da modularidade e que sua implementa o seja monolitica Em alguns casos como forma de evitar desperd cio de tempo de processamento e de mem ria em chamadas de procedimentos salvamento e recupera o de contexto imp e se o desenvolvimento de um programa sem a utiliza o de fun es e procedimentos Ainda assim uma vez que o projeto seguiu uma filosofia de modularidade o software dever apresentar alguns benef cios resultantes da ado o deste princ pio 34 A Aroumerura De Sortware O conceito de arquitetura de software est ligado aos dois principais aspectos do funcionamento de um software a estrutura hier rquica de seus componentes ou m dulos e as estruturas de dados A arquitetura de software resulta do desenvolvimento de atividades de particionamento de um problema
225. sentido cl ssico e o software n o se desgasta ou seja ao contr rio da maioria dos produtos o software n o se caracteriza por um aumento na possibilidade de falhas medida que o tempo passa como acontece com a maioria dos produtos manufaturados e a maioria dos produtos de software concebida inteiramente sob medida sem a utiliza o de componentes pr existentes Em fun o destas caracter sticas diferenciais o processo de desenvolvimento de software pode desembocar um conjunto de problemas os quais ter o influ ncia direta na qualidade do produto Tudo isto porque desde os prim rdios da computa o o desenvolvimento dos programas ou a programa o era visto como uma forma de arte sem utiliza o de metodologias formais e sem qualquer preocupa o com a documenta o entre outros fatores importantes A experi ncia do programador era adquirida atrav s de tentativa e erro A verdade que esta tend ncia ainda se verifica Com o crescimento dos custos de software em rela o aos de hardware no custo total de um sistema computacional o e qu CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA processo de desenvolvimento de software tornou se um item de fundamental import ncia na produ o de tais sistemas A n vel industrial algumas quest es que caracterizaram as preocupa es com o processo de desenvolvimento de software foram e por que o software demora tanto pa
226. senvolvimento de software atrav s de pol ticas normas e estruturas organizacionais as quais geram uma infra estrutura e uma cultura de suporte aos m todos e procedimentos de desenvolvimento 5 2 N veis De maturpane no PROCESSO De DESENVOLVIMENTO De SoFtwaRe O modelo CMM define cinco n veis de maturidade no que diz respeito ao processo de desenvolvimento de software adotado a n vel das empresas estabelecendo uma escala ordinal que conduz as empresas ao longo de seu aperfei oamento Um n vel de maturidade um patamar de evolu o de um processo de desenvolvimento de software correspondendo a um degrau na evolu o cont nua de cada organiza o A cada n vel corresponde um conjunto de objetivos que uma vez atingidos estabilizam um componente fundamental do processo de desenvolvimento de software tendo como conseq ncia direta o aumento da capabilidade da empresa A figura 2 1 apresenta os cinco n veis de maturidade propostos no modelo CMM na qual se pode observar tamb m o estabelecimento de um conjunto de a es que permitir o a uma empresa subir de um degrau para o outro nesta escala 5 2 1 N vel Iniciar No n vel inicial o desenvolvimento de software realizado de forma totalmente ad hoc sem uma defini o de processos No caso de problemas que venham a ocorrer durante a realiza o de um projeto a organiza o tem uma tend ncia a abandonar totalmente os procedimentos planejados e passa a um processo d
227. sofisticadas serem dotadas de fun es de an lise do fluxo de dados do programa 3 1 2 Os Testes Din micos Os testes din micos s o os procedimentos baseados na execu o do c digo bin rio do programa sendo esta execu o realizada com base em subconjuntos de dados o jogo de teste A escolha do subconjunto de dados a ser utilizado para o teste pode ser feita com base em aspectos estruturais do software obtido a partir do c digo fonte ou em aspectos funcionais a partir da especifica o do programa 3 2 testes De mpane mtecRa o vaLIDa o e sistema Uma outra forma de subdividir o teste de software quanto ao seu objetivo na busca por erros do programa Sob este ponto de vista encontra se os seguintes tipos de teste 3 2 1 O Teste de Unidade O teste de unidade objetiva a verifica o de erros existentes nas unidades de projeto do mesmo qual daremos o nome de m dulo Nesta modalidade de teste importante utilizar as informa es contidas no documento de projeto detalhado do software as quais servir o de guia para sua aplica o O teste de unidade de certa forma uma t cnica de teste de caixa branca podendo ser realizado em paralelo sobre diferentes m dulos 3 2 2 O Teste de Integra o O Teste de Integra o como o nome indica objetiva a busca de erros surgidos quando da integra o das diferentes unidades componentes do software E importante lembrar que o fato de se ter analisado
228. suporte a constru es que possam ser identificadas em blocos O leitor identifica um conjunto de instru es a partir da visualiza o de um de seus componentes Por exemplo as constru es do tipo IF THEN ELSE REPEAT UNTIL entre outras s o exemplos de constru es que aumentam a caracter stica de localidade numa linguagem Ef CAP 7 LINGUAGENS DE PROGRAMA O PROF Vit rio BRUNO MAZZOLA 3 1 5 Linearidade A linearidade est relacionada manuten o do dom nio funcional ou seja a percep o melhorada quando uma seq ncia de instru es l gicas encontrada Programas caracterizados por grandes ramifica es violam esta caracter stica 3 2 Caracter sticas De ncenxaria Numa vis o de engenharia de software as caracter sticas das linguagens de programa o est o relacionadas s necessidades do processo de desenvolvimento do software Algumas caracter sticas que podem ser derivadas segundo esta tica s o 3 2 1 Facilidade de deriva o do c digo fonte Esta caracter stica est ligada proximidade da sintaxe da linguagem de programa o com as linguagens de representa o de projeto Na maior parte dos casos as linguagens que suportam constru es estruturadas estruturas de dados relativamente complexas possibilidade de manipula o de bits constru es orientadas a objetos e constru es de entrada sa da especializadas permitem mapear mais facilmente as representa es de pro
229. tamb m ser considerados opera es Apesar que uma implementa o possa ser organizada de forma diferente da que o DFD representa por causa de otimiza o Cada opera o pode ser especificada de v rias formas como por exemplo fun es matem ticas tabelas de valores de entrada e sa da equa es especificando sa da em termos de entrada pr e p s condi es tabelas de decis o pseudo c digo e linguagem natural Y Rela es entre mopeLos Cada modelo descreve um aspecto do sistema mas contem referencias aos outros modelos O modelo objeto descreve a estrutura de dados sobre a qual os modelos din mico e funcional operam As opera es no modelo objeto correspondem aos eventos no modelo din mico e as fun es no modelo funcional O modelo din mico descreve a estrutura de controle dos objetos As a es no diagrama de estados correspondem as fun es no diagrama funcional Os eventos no diagrama de estados se tornam as opera es no modelo objeto O modelo funcional descreve as fun es invocadas pelas opera es no modelo objeto e a es no modelo din mico As fun es operam sobre as valores de dados especificados pelo modelo objeto O modelo funcional mostra ainda as restri es sobre os valores objeto 5 AN LISE ORIENTADA A OBJETOS A fase de an lise diz respeito ao entendimento e modelagem da aplica o e do dom nio no qual ela opera Esta fase focaliza o que necessita ser feito e n o como deve ser feit
230. tem ao gerente uma avalia o do estado de evolu o do processo Um indicador de progresso considerado atingido ou satisfeito quando a documenta o produzida com rela o a este indicador revisada e aprovada o q qr CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA 3 3 R Distrisu o Do SFOR O Normalmente as t cnicas de estimativas para projetos de software conduzem a uma defini o do esfor o em termos do n mero de homens m s ou homens ano necess rias para realizar o desenvolvimento do projeto Uma proposta de distribui o de esfor o bastante utilizada nos projetos aquela ilustrada na figura 4 4 a qual baseada numa regra anteriormente denominada Regra 40 20 40 a qual sugere como etapas onde o esfor o deve ser maior as dos extremos do processo de desenvolvimento an lise projeto e testes a codifica o sendo a tarefa que deve envolver a menor concentra o de esfor o Isto pode ir contra o grau de import ncia em termos de esfor o que muitos desenvolvedores d o a cada uma destas atividades E evidente que estes valores n o podem ser levados risca para todos os projetos de software sendo que as caracter sticas de cada projeto vai influenciar na parcela de esfor o a ser dedicada a cada etapa No entanto importante entender a raz o pela qual o esfor o dedicado etapa de codifica o aparece com menor intensidade que os demais Na realidade se a eta
231. tente normalmente muito dif cil de manter em opera o o que significa que o custo do software acaba sendo incrementado significativamente devido s atividades relacionadas manuten o isto um reflexo da pouca import ncia dada manutenibilidade no momento da concep o dos sistemas 2 2 Sortware Mros e ReaLipaDe poss vel apontar como causas principais dos problemas levantados na se o anterior tr s principais pontos a falta de experi ncia dos profissionais na condu o de projetos de software e a falta de treinamento no que diz respeito ao uso de t cnicas e m todos formais para o desenvolvimento de software e a cultura de programa o que ainda difundida e facilmente aceita por estudantes e profissionais de Ci ncias da Computa o e a incr vel resist ncia s mudan as particularmente no que diz respeito ao uso de novas t cnicas de desenvolvimento de software que os profissionais normalmente apresentam Entretanto importante ressaltar e discutir os chamados mitos e realidades do software o que de certo modo explicam alguns dos problemas de desenvolvimento de software apresentados did CAP 1 ENGENHARIA DE SOFTWARE CONCEITOS B SICOS PROF VIT RIO BRUNO MAZZOLA 2 2 1 Mitos de Gerenciamento Mito 1 Se a equipe disp e de um manual repleto de padr es e procedimentos de desenvolvimento de software ent o a equipe est apta a encaminhar bem o desenvolvimento
232. ticamente todas as linguagens de programa o oferecem mecanismos para a defini o de estruturas de dados com diferentes escopos Neste teste deve ser verificado o bom uso destes mecanismos e se esta utiliza o est sendo feita de modo coerente com o que foi estabelecido no projeto Os erros mais comuns detectados neste tipo de teste s o e digita o inconsistente ou impr pria por exemplo identificadores de uma vari vel ou tipo de dados digitados de forma incorreta e inicia o incorreta de vari veis valores iniciais incorretos inconsist ncia nos tipos de dados e underflow e overflow 4 1 3 O teste de condi es limite Este teste busca verificar que o que foi definido a n vel de projeto para as condi es limite de uma unidade est sendo respeitado a n vel de implementa o Por exemplo um m dulo encarregado de implementar um mecanismo de temporiza o deve ser testado para observar se o tempo m ximo de espera est compat vel com o que foi especificado 4 1 4 O teste de caminhos de execu o O sucesso da realiza o deste tipo de teste depende fortemente da complexidade do algoritmo implementado a n vel da unidade sob teste E que neste caso necess rio que os casos de teste a serem aplicados permitam percorrer os diversos caminhos de execu o da unidade os quais ser o em maior n mero quanto mais complexa for a unidade Os erros mais comuns verificados neste tipo de teste s o 8 6
233. tiva dificuldade considerando alguns aspectos e geralmente os clientes n o entendem de software ou do processo de desenvolvimento de um programa e o desenvolvedor usualmente n o entende do sistema no qual o software vai executar Estes dois aspectos provam que existem efetivamente um problema de comunica o a ser resolvido para que o processo de desenvolvimento seja bem sucedido A import ncia desta etapa est no fato de que atrav s dela que as id ias do cliente sobre o problema a ser resolvido pelo sistema a desenvolver s o expressas na forma de um documento se poss vel que utilize ferramentas formais Uma An lise de Requisitos bem sucedida deve normalmente representar corretamente as necessidades do cliente e dos usu rios satisfazendo por m s tr s partes envolvidas incluindo o desenvolvedor O que verificado em boa parte dos projetos de software que o cliente nem sempre entende perfeitamente quais s o as suas reais necessidades assim como os usu rios t m dificuldades para exprimir as suas expectativas com rela o ao que est sendo desenvolvido Um primeiro resultado desta etapa deve ser sem d vida o esclarecimento a respeito do que s o estas necessidades e expectativas A obten o bem sucedida de informa es um fator preponderante para o sucesso da An lise de Requisitos particularmente nas duas primeiras tarefas descritas anteriormente A compila o das informa es relevantes para o
234. to efetivo dos seus projetos de software de modo que o sucesso de projetos anteriores possam ser repetidos nos projetos em curso Neste n vel os requisitos do software e o trabalho a ser feito para satisfaz los s o planejados e supervisionados ao longo da realiza o do projeto S o definidos padr es de projeto e a institui o deve garantir a sua efetiva implementa o A capabilidade de uma empresa situada neste n vel pode ser caracterizada como disciplina em raz o dos esfor os de gerenciamento e acompanhamento do projeto de software 5 2 3 N vel Dermio No n vel definido o processo de desenvolvimento de software consolidado tanto do ponto de vista do gerenciamento quanto das tarefas de engenharia a realizar isto feito atrav s de documenta o padroniza o e integra o no contexto da organiza o que adota esta vers o para produzir e manter o software Os processos definidos nas organiza es situadas neste n vel s o utilizados como refer ncia para os gerentes de projeto e os membros do staff t cnico sendo baseado em pr ticas propostas pela Engenharia de Software 2 CAP 2 QUALIDADE DE SOFTWARE PROF Vit rio BRUNO MAZZOLA Programas de treinamento s o promovidos ao n vel da organiza o como forma de difundir e padronizar as pr ticas adotadas no processo definido As caracter sticas particulares de cada projeto podem influir no aprimoramento de um processo de desenvolvimento se
235. to que deve ser tratado com especial aten o pelo projetista os softwares onde a intera o feita atrav s de uma linguagem de comandos correspondem a uma abordagem que tende a desaparecer dando lugar ao uso de t cnicas de point and pick baseadas no uso de janelas e tendo o mouse como ferramenta essencial de entrada de dados e comandos de todo modo mesmo softwares com interfaces gr ficas de ltima gera o podem oferecer ao usu rio uma op o de uso do teclado para todas ou pelo menos para as mais importantes fun es dispon veis no software os atalhos de teclado um outro aspecto presente em aplica es mais recentes o conceito de macros que podem ser definidos pelo usu rio para armazenar as sequ ncias mais comuns de uso do software segundo este conceito ao inv s de digitar todos os comandos necess rios realiza o de uma dada tarefa o usu rio digita simplesmente o nome do macro um ltimo aspecto relacionado aos comandos o uso de padroniza es em rela o aos r tulos ou atalhos de teclado um exemplo claro deste tipo de padroniza o est na maior parte das aplica es constru das para os ambientes gr ficos que utilizam o mesmo r tulo para a es compat veis como as a es de c pia e reprodu o de blocos de texto ou gr fico copy paste as a es de salvamento de arquivos save save as o abandono de um programa exit 6 2 4 A Implementa o de Interfaces O projeto de uma interf
236. tos s o explicitamente ordenados o que representado por ordered perto da indica o de multiplicidade Qualifica o Uma associa o qualificada relaciona duas classes de objetos e um qualificador O qualificador um atributo especial que reduz a multiplicidade efetiva de uma associa o distinguindo objetos dentro do conjunto na extremidade v rios da associa o Autorizado em lt Workstation Autoriza o prioridade privil gios in cio sess o diret rio home Diret rio Figura 9 10 Modelando uma associa o como Classe 9 9 CAP 9 AN LISE E PROJETO ORIENTADOS A OBJETOS PROF VIT RIO BRUNO MAZZOLA 4 1 4 Agrega o A agrega o uma rela o parte todo ou uma parte de na qual os objetos representando os componentes de algo s o associados com um objeto representando a jun o deles assembly Algumas propriedades da classe jun o se propagam s classes componentes possivelmente com alguma modifica o local A agrega o definida como uma rela o entre uma classe jun o e uma classe componente A agrega o ent o uma forma especial de associa o A simbologia da agrega o similar a da associa o linha exceto pelo fato de um pequeno losango indicar o lado da jun o da rela o conforme a figura 9 11 4 1 5 Generaliza o e heran a Generaliza es e heran a s o abstra es poderosas que permitem compart
237. tribu ram tamb m de forma bastante significativa as constantes quedas de pre o do hardware Uma consequ ncia deste crescimento foi a necessidade cada vez maior de desenvolver grandes sistemas de software em substitui o aos pequenos programas aplicativos utilizados at ent o Desta necessidade surgiu um problema nada trivial devido falta de experi ncia e n o adequa o dos m todos de desenvolvimento existentes para pequenos programas o que foi caracterizado ainda na d cada de 60 como a crise do software mas que por outro lado permitiu o nascimento do termo Engenharia de Software Atualmente apesar da constante queda dos pre os dos equipamentos o custo de desenvolvimento de software n o obedece a esta mesma tend ncia Pelo contr rio corresponde a uma percentagem cada vez maior no custo global de um sistema informatizado A principal raz o para isto que a tecnologia de desenvolvimento de software implica ainda em grande carga de trabalho os projetos de grandes sistemas de software envolvendo em regra geral um grande n mero de pessoas num prazo relativamente longo de desenvolvimento O desenvolvimento destes sistemas realizado na maior parte das vezes de forma ad hoc conduzindo a frequentes desrespeitos de cronogramas e acr scimos de custos de desenvolvimento O objetivo deste curso apresentar propostas de solu es s quest es relacionadas ao desenvolvimento de software atrav s da transfe
238. uagem Pascal deu um impulso importante neste aspecto com a possibilidade do usu rio construir tipos de dados mais complexos a partir dos tipos b sicos e de seus construtores Este mecanismo est presente em praticamente todas as linguagens em uso nos dias de hoje 5 3 R Constru o ne Instru es O fluxo l gico de instru es definido normalmente durante a etapa de projeto projeto detalhado Entretanto o mapeamento deste fluxo l gico em instru es individuais faz parte do trabalho de codifica o Um aspecto que deve ser explorado durante a constru o das instru es a simplicidade Utilizar as possibilidades que algumas linguagens oferecem de escrever mais de uma instru o por linha por exemplo sem d vida uma decis o que vai contra a clareza do c digo independente da economia de espa o e de papel que isto pode representar Abaixo s o apresentadas algumas regras importantes no que diz respeito a este aspecto e evitar o uso de testes condicionais complicados ou que verifiquem condi es negativas evitar o intenso aninhamento de la os ou condi es utilizar par nteses para evitar a ambiguidade na representa o de express es l gicas ou aritm ticas utilizar s mbolos de espa amento para esclarecer o conte do de uma instru o 54 ntRanas Sainas As entradas de dados num software podem ser realizadas de forma interativa ou em batch Independente da forma como as entradas ser o e
239. ual peso 2 4 Anmmistra o e Monnrora o Dos Riscos Uma vez avaliados os riscos de desenvolvimento importante que medidas sejam tomadas para evitar a ocorr ncia dos riscos ou que a es sejam definidas para a eventualidade da ocorr ncia dos riscos Este o objetivo da tarefa de Administra o e monitora o dos riscos Para isto as informa es mais importantes s o aquelas obtidas na tarefa anterior relativa descri o probabilidade de ocorr ncia e impacto sobre o processo associadas a cada fator de risco breakpoint Ultrapassagem dos prazos Ultrapassagem dos custos Figura 4 1 Ilustra o de uma situa o de defini o de dois n veis de riscos Por exemplo considerando a alta rotatividade de pessoal numa equipe um fator de risco com base em dados de projetos passados obt m se que a probabilidade de ocorr ncia deste risco de 0 70 muito elevada e que a sua ocorr ncia pode aumentar o prazo do projeto em 15 e o seu custo global em 12 Sendo assim pode se propor as seguintes a es de administra o deste fator de risco gji CAP 4 PLANEJAMENTO DO DESENVOLVIMENTO DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA reuni es com os membros da equipe para determinar as causas da rotatividade de pessoal m s condi es de trabalho baixos sal rios mercado de trabalho competitivo etc tomada de provid ncias para eliminar ou reduzir as causas control veis antes do
240. ulo diagrama A31 A32 A33 Figura 5 17 Exemplo de um ndice de N s 5 21 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA t tulo diagrama t tulo diagrama A1 t tulo diagrama A2 t tulo diagrama t tulo diagrama t tulo diagrama A31 A32 A33 Figura 5 18 Exemplo de uma Tabela de N s t tulo diagrama A3 8 2 5 A An lise de um Diagrama A leitura de um diagrama deve ser efetuada segundo um caminho principal que parte da seta de entrada ou de controle n o conectada mais importante e chega na seta de sa da n o conectada mais importante As seguintes regras devem ser observada quando da an lise de uma diagrama examinar apenas os blocos do diagrama sob an lise retornar ao diagrama pai para observar como as setas C O e M est o conectadas no bloco pai e qual a sua configura o no diagrama filho Q identificar a seta de entrada ou de controle e a seta de sa da mais importantes do diagrama amp examinar o diagrama percorrendo o caminho principal 1 j2 13 N Ci C2 12 gt 02 Figura 5 19 Exemplo de etiquetagem das setas num diagrama 5 22 CAP 5 AN LISE DE REQUISITOS PROF VIT RIO BRUNO MAZZOLA percorrer o diagrama observando como as diferentes setas interv m em cada caixa e definindo os caminhos secund rios ler as notas associadas ao diagrama para um melhor entendimento 8 2 6 Normas
241. uma vis o global da arquitetura do software O que estiver definido a n vel do projeto da arquitetura do software vai ter sem d vida grande impacto nas defini es relativas aos demais projetos LY O Projeto ProcenimentaL O projeto procedimental encaminhado a partir da defini o da estrutura do software Devido riqueza de detalhes que pode caracterizar o projeto procedimental a ado o de nota es adequadas ao projeto uma necessidade como forma de evitar a indesej vel ambiguidade que poderia ser resultante da utiliza o por exemplo da linguagem natural 4 4 1 A Programa o estruturada A programa o estruturada introduzida no final dos anos 60 foi uma interessante forma de se encaminhar projetos e implementa es de software oferecendo facilidade de programa o e de entendimento A id ia por tr s da programa o estruturada a utiliza o de um conjunto limitado de constru es l gicas simples a partir das quais qualquer programa poderia ser constru do Cada constru o apresentava um comportamento l gico previs vel iniciando no topo e finalizando na base o que propiciava ao leitor um melhor acompanhamento do fluxo procedimental Independente da linguagem utilizada para a implementa o ela era composta basicamente de tr s classes de constru es as sequ ncias as condi es e as repeti es O uso de um n mero limitado de constru es simples as quais podem ser combinadas das mais var
242. upa o conduzida neste momento assim como a defini o de esquemas de instala o e manuten o Um dos resultados da Engenharia de Sistemas a defini o de aspectos como funcionalidade e desempenho do software O trabalho essencial do engenheiro de software acomodar os requisitos de funcionalidade e desempenho da forma mais eficiente poss vel tendo que para isto adquirir e ou desenvolver os componentes de software A dificuldade que surge na Engenharia de Software a falta de padroniza o nos componentes de Qi CAP 3 ENGENHARIA DE SISTEMAS COMPUTACIONAIS PROF VIT RIO BRUNO MAZZOLA software o que n o ocorre no caso do hardware uma vez que na maior parte dos projetos estes componentes s o customizados para atender s exig ncias de software do sistema a ser desenvolvido Como j foi discutido anteriormente a Engenharia de Software envolve as seguintes fases Defini o que iniciada com o Planejamento do Desenvolvimento do Software englobando todas as tarefas discutidas no cap tulo Ill do curso obtendo um documento de Plano do Software o qual ser produzido e revisado pelo Gerente do Projeto ainda nesta fase realizada a An lise de Requisitos do Softwa a qual vai permitir que fun es dentro do sistema como um todo ser o atribu das ao software a ltima tarefa relacionada a esta fase a revis o da Especifica o de Requisitos do Software o qual o documento resultante da An l
243. valia o dos riscos processar as informa es sobre o fator de risco o impacto do risco e a probabilidade de ocorr ncia Nesta avalia o ser o checadas as informa es obtidas na proje o de riscos buscando prioriz los e definir formas de controle destes ou de evitar a ocorr ncia daqueles com alta probabilidade de ocorr ncia Para tornar a avalia o eficiente deve ser definido um n vel de risco referente Exemplos de n veis referentes t picos em projetos de Engenharia de Software s o o custo o prazo e o desempenho Isto significa que se vai ter um n vel para o excesso de custo para a ultrapassagem de prazo e para a degrada o do desempenho ou qualquer combina o dos tr s Desta forma caso os problemas originados por uma combina o de determinados riscos provoquem a ultrapassagem de um ou mais desses n veis o projeto poder ser suspenso Normalmente poss vel estabelecer um limite denominado de ponto referente breakpoint onde tanto a decis o de continuar o projeto ou de abandon lo podem ser tomadas A figura 4 1 ilustra esta situa o na qual dois n veis de risco referente s o considerados o custo e o prazo Se uma conbina o de riscos conduzir a uma situa o onde os limites de ultrapassagem de custo e ou de prazo estejam acima do limite delimitado pela curva na figura o projeto ser abandonado rea em cinza escuro No breakpoint as decis es de continuar o projeto ou abandon lo t m ig
244. ventuais solu es o analista deve levar em conta as estimativas e as restri es de projeto Este processo de avalia o e s ntese prossegue at que o analista e o cliente estejam de acordo sobre a adequa o das especifica es realizadas para a continuidade do processo 2 3 A Movezacem A partir da tarefa de avalia o e s ntese o analista pode estabelecer um modelo do sistema o qual permitir uma melhor compreens o dos fluxos de informa o e de controle assim como dos aspectos funcionais e de comportamento Este modelo ainda distante de um projeto detalhado servir de refer ncia s atividades de projeto assim como para a cria o da especifica o de requisitos Em muitas situa es como forma de refor ar o conhecimento sobre a viabilidade do software a ser desenvolvido pode ser necess rio o desenvolvimento de um prot tipo de software como alternativa ou como trabalho paralelo an lise de requisitos Este ponto ser discutido mais adiante neste documento 2 4 sprecmica o nos Requisitos e Revis o A etapa de An lise de Requisitos culmina com a produ o de um documento de Especifica o de Requisitos de Software o qual registra os resultados das tarefas realizadas Eventualmente pode ser produzido como documento adicional um Manual Preliminar do Usu rio Embora pare a estranho a produ o deste manual permite que o analista passe a olhar para o software da tica do cliente usu rio o que pode s
245. versos o que pode ser um verdadeiro atentado robustez de um sistema Da mesma forma dados de sa da ou formatos de apresenta o de resultados podem parecer timos para o analista mas completamente inadequados para o usu rio Quando um software constru do sob demanda uma bateria de testes de aceita o conduzida envolvendo o cliente A dura o dos testes de aceita o pode variar entre algumas semanas e v rios meses dependendo da complexidade ou natureza da aplica o No caso de um software de prateleira aquele software que constru do para um segmento do mercado de software e que destinado utiliza o por um grande conjunto grande de usu rios os editores de software fazem uso de um processo denominado teste alfa e teste beta 6 3 1 Testes Alfa Os testes alfa s o realizados com base no envolvimento de um cliente ou numa amostra de clientes sendo realizado nas instala es do desenvolvedor do software O software utilizado num ambiente natural sendo que o desenvolvedor observa o comportamento do cliente e vai registrando as anomalias detectadas durante a utiliza o 6 3 2 Testes Beta J os testes beta s o conduzidos em uma ou mais instala es do cliente pelo usu rio final do software Software DD a Requisitos gt Teste de Valida o Software v lido Documento do usu ri Aprova o Revis o de Configura o Documento do pda Ra Docum
246. volver e manter software e seus produtos associados planos de projeto documentos de projeto c digo casos de teste e manuais de usu rio Uma empresa considerada num maior grau de maturidade quanto mais evolu do for o seu processo de desenvolvimento de software D p CAP 2 QUALIDADE DE SOFTWARE PROF VIT RIO BRUNO MAZZOLA A Capabilidade de um processo de software est relacionada aos resultados que podem ser obtidos pela sua utiliza o num ou em v rios projetos Esta defini o permite estabelecer uma estima o de resultados em futuros projetos O Desempenho de um processo de software representa os resultados que s o correntemente obtidos pela sua utiliza o A diferen a b sica entre estes dois conceitos est no fato de que enquanto o primeiro est relacionado aos resultados esperados o segundo relaciona se aos resultados que foram efetivamente obtidos A Maturidade de um processo de software estabelece os meios pelos quais ele definido gerenciado medido controlado e efetivo implicando num potencial de evolu o da capabilidade Numa empresa com alto grau de maturidade o processo de desenvolvimento de software bem entendido por todo o staff t cnico gra as exist ncia de documenta o e pol ticas de treinamento e que este continuamente monitorado e aperfei oado por seus usu rios A medida que uma organiza o cresce em termos de maturidade ela institucionaliza seu processo de de
247. ware deve antes de tudo ser visto como um elemento de um sistema mais amplo ao qual denominaremos um Sistema Computacional No contexto deste curso um Sistema Computacional dever ser entendido como o resultado da uni o de diferentes componentes entre os quais se enquadram o software o hardware e elementos de outras naturezas como por exemplo o elemento humano representado pelo usu rio do sistema A Engenharia de Sistemas Computacionais corresponde ao conjunto de atividades que dever o ser realizadas para definir o sistema computacional como um todo Dentre as atividades a serem conduzidas pode se citar a especifica o o projeto a implementa o a valida o a instala o e a manuten o Cada uma das disciplinas componentes da Engenharia de Sistemas est relacionada a uma tentativa de estabelecimento de uma ordem no desenvolvimento de sistemas computacionais Nestes sistemas o software vem h muitos anos substituindo o hardware como o elemento de mais dif cil concep o com menor probabilidade de sucesso em termos de prazos e custo e de mais dif cil administra o Al m disso a demanda por software cresce a cada dia at como consequ ncia do grande desenvolvimento do hardware dos sistemas computacionais O objetivo deste cap tulo discutir as principais defini es e aspectos relacionados com a Engenharia de Sistemas Computacionais procurando definir o papel da Engenharia de Software neste contexto 2 RSPEC
248. xemplo texto estruturado diagramas de estado etc e que o espa o ocupado pela descri o n o ultrapasse uma nica p gina 8 2 3 Refer ncia aos Diagramas A refer ncia de cada diagrama localizada no canto esquerdo inferior da folha de cada diagrama sendo que cada refer ncia definida como sendo um n O n especificado pela letra A seguida de um n mero que indique o bloco pai que est sendo detalhado Cada bloco num diagrama apresenta um n mero de refer ncia escrito no seu canto superior direito o qual o identifica de forma nica para aquele diagrama A figura 5 16 ilustra a forma de refer ncia aos diagramas e aos blocos num diagrama 519 CAP 5 AN LISE DE REQUISITOS PROF Vit rio BRUNO MAZZOLA A1 gt 01 n 02 3 gt m2 A13 m gt 01 k m4 Figura 5 15 Exemplo de refinamento de um bloco num actigrama A representa o da estrutura hier rquica do modelo completo do sistema pode ser representada em duas formas distintas um ndice de n s como mostra a figura 5 17 uma tabela de n s como mostrado na figura 5 18 8 2 4 Etiquetagem das Setas Uma regra importante a ser seguida a qual reflete fortemente na consist ncia do modelo em realiza o que durante o refinamento de uma caixa nenhuma adi o ou supress o de informa o deve ser feita particularmente no que diz respeito s interfaces entradas sa das controles e mecanismos e

Engenharia de Software

Contents

Download Pdf Manuals

Related Search

Related Contents