Anlise e Projeto Orientado a Objetos

Bem vindos!

http://w w w .w ix.com/alvarofpinheiro/pessoal Verso 2011.1 Documento atualizado em 04/06/2011 Pa ra imprimir clique no bot o

Sobre o curso: Bacharel em Sistemas de Informao, uma atividade que cada vez mais se torna necessria no mundo corporativo. Quem se forma em SI planeja e organiza o processamento, o armazenamento e a recuperao de informaes e disponibiliza esse material para os usurios. Cria programas para facilitar as atividades corporativas e monta e gerencia bancos de dados. Alm disso, administra o fluxo de informaes gerado e distribudo dentro de uma empresa. A formao continuada essencial para o profissional de Sistemas de Informao, pois a cada dia surgem novos recursos e ferramentas e especializar-se vital nessa rea. O mercado de trabalho na rea continua e aquecida. Sobre a disciplina: Para se desenvolver um produto de software necessrio em primeiro lugar se definir qual o processo de desenvolvimento dever ser usado. Podendo ser o SWEBOK do Software Engineering Institute (SEI), ou o Rational Unified Process (RUP) como processo recomendado para o paradigma orientado a objetos. Alm de uma srie de outras tcnicas e processos j amadurecidos, como o SCRUM e o XP, mais na frente sero abordados com detalhes. Bom estudo!

Hoje dom

junho de 2011
seg 29 30 ter 31 qua 1 de jun qui

Imprimir Semana Ms
sex 2 3

Compromissos
sb 4

1A PO O 08:00 N A BU C O 2 0 1 1 18:30 FI R 2 0 1 1 1 L A BP O O (SA L A 3 4 )

18:30 FI R2 0 1 1 A P O O (SA L A 3 4 )

9
18:30 FI R2 0 1 1 A P O O (SA L A 3 4 )

10

11

1A PO O 08:00 N A BU C O 2 0 1 1 18:30 FI R 2 0 1 1 1 L A BP O O (SA L A 3 4 )

12

13

14

15

16
18:30 FI R2 0 1 1 A P O O (SA L A 3 4 )

17

18

1A PO O 08:00 N A BU C O 2 0 1 1 18:30 FI R 2 0 1 1 1 L A BP O O (SA L A 3 4 )

19

20

21

22

23
18:30 FI R2 0 1 1 A P O O (SA L A 3 4 )

24

25

1A PO O 08:00 N A BU C O 2 0 1 1 18:30 FI R 2 0 1 1 1 L A BP O O (SA L A 3 4 )

26

27

28

29

30
08:00 N A BU C O 2 0 1 1 1 A P O O 18:30 FI R2 0 1 1 A P O O (SA L A 3 4 )

1 de jul

Ev entos mostrados no f uso horrio: Recif e

Primeira Avaliao As atividades formativas (exerccios postados no final de cada aula) computam 4 pontos e a atividade somativa (avaliao objetiva/subjetiva do final da primeira unidade) computa 6 pontos. Segunda Avaliao As atividades formativas (exerccios postados no final de cada aula) computam 2 pontos e a atividade somativa (avaliao objetiva/subjetiva no final da segunda unidade) computa 8 pontos. Terceira Avaliao ou Segunda Chamada ou Final Atividade somativa (avaliaes objetiva/subjetiva no final do semestre) de todas as aulas contidas no site, material de referncia e complementar computando 10 pontos.

AULA 01 - Desenvolvimento de Software

Por que necessrio se buscar qualidade no desenvolvimento de software? Ao entrar no restaurante, a hostess lhe informa, gentil e sorridente, dos resultados de uma pesquisa sobre os trinta mil ltimos pedidos realizados na casa. Em nmeros redondos, 28% dos pratos servidos eram o que os fregueses haviam pedido, chegaram no tempo previsto e pelo preo do cardpio. Em 49% dos casos, alguma coisa deu errado no prato, no preo, no prazo ou numa combinao de todos. Teve gente que pediu bacalhau e recebeu tapioca, pelo mesmo preo, tempos depois. Em muitos casos, as discusses quase chegaram s vias de fato; em pelo menos um, o cliente sacou uma 9000S e queria mandar o chef direto para o banquete celestial. Enfim, nos outros 23% dos pedidos, os pratos e os clientes no se encontraram nunca; s vezes porque os primeiros demoraram tanto que os clientes desistiram; noutras, porque o chef veio mesa, mais de uma vez, para aumentar o preo; noutras, porque o cliente descobriu que o prato ia chegar, mas seria muito diferente do pedido. Em suma, sua chance de sair dali realmente satisfeito de 28%; a pergunta que a hostess lhe faz ... Posso levar-lhe mesa, senhor? Voc iria ou no? Nunca vi nenhuma recepo assim, em restaurante nenhum. At porque a vasta maioria deles tem um recorde melhor do que este. Mas no acho que entraria num buraco, por mais chique que fosse, onde minha chance de ser bem servido, comer bem e pagar o combinado fosse uma em quatro. E no acho que haja tantos gastro-masoquistas por a, a ponto de manter restaurantes do tipo acima abertos. S que os nmeros dizem respeito a projetos de software e so do Standish Group, empresa que realiza, desde 1994, um levantamento bastante sofisticado sobre projetos de software realizados em empresas norte-americanas. O campo frtil, pois o gasto anual americano em projetos de aplicaes de software chega a US$275 bilhes, com mais de 200 mil projetos em andamento. O Standish Group levantou a histria de 30 mil desses projetos desde 1994 e, para alguns deles,

em andamento. O Standish Group levantou a histria de 30 mil desses projetos desde 1994 e, para alguns deles, realizou estudos detalhados. Os dados e as concluses revelam o tamanho dos problemas que ainda existem em desenvolvimento de software, bem como o tamanho da oportunidade para quem tentar e conseguir resolv-los. A situao vem melhorando, e de forma muito significativa em alguns aspectos. Em 1994, o aumento mdio de preo nos projetos chegava a 189%, tendo cado para 45% em 2000. Uma senhora queda, diga-se no to de passagem assim, que reflete o aumento da preocupao, ateno e da competncia mundial em relao ao desenvolvimento de software, que est passando a ser a ferramenta mais bsica e fundamental dos processos econmicos e sociais. quase impossvel se passar um dia sem sofrer o efeito de algum tipo de sistema de informao; para nosso bem, portanto, bom que eles funcionem, a contento, no prazo e no preo que, por exemplo, o supermercado combinou. Seno, sempre pagaremos uma parte do prejuzo, seja em aumento de preos e/ou piores servios, ou em diminuio de competio, pois software de m qualidade, fora do prazo ou muito caro (ou os trs, vez por outra) pode ser falncia certa. Um dos casos mais rumorosos pode ter destrudo, em 1996, um dos maiores distribuidores de medicamentos dos EUA, a FoxMeyer Drug Co., que faturava US$5 bilhes por ano. Os liquidantes processaram a SAP e a Andersen Consulting (hoje Accenture), pedindo uma compensao de US$ 1 bilho, processo que dever ser julgado este ano, correndo o risco de criar jurisprudncia nos EUA. Alguns crticos acham que as companhias no aprendem com fracassos anteriores, mas o fato que o estado da prtica de construo de software vem mudando, e para muito melhor, nos ltimos 15 anos. Segundo dados do mesmo estudo do Standish Group, o atraso mdio dos projetos de software caiu de 222% do tempo inicialmente previsto, em 1994, para 63% em 2000; em 1994, apenas 61% da funcionalidade prevista era entregue, em mdia, nmero que subiu para 67%. Pode no ser essas coisas todas saber que sua encomenda de software, se estiver na mdia, custar 45% mais caro do que o contratado, ter um atraso de 63% sobre o prazo previsto para entrega e no ter 33% das funcionalidades encomendadas. Mas h de se convir (compare acima) que houve um progresso gigantesco. Construir software no uma atividade simples; o problema que se trata normalmente o da replicao virtual de processos, sistemas e, na maioria das vezes, instituies e redes delas. Fazer com que o item cujo estoque caiu abaixo do mnimo seja encomendado e reposto na prateleira do supermercado muito fcil... desde que todos os processos, sistemas e instituies envolvidos sejam individualmente entendidos e se entendam entre si. Na maioria dos casos, muito difcil, em projetos complexos, de porte e de longo prazo, manter a instituio esttica, esperando que o projeto se complete. Na prtica, os requisitos que um grande sistema tem que atender vo mudando medida em que ele vai sendo construdo, como se seu pedido para a cozinha do restaurante fosse sendo mudado enquanto est sendo preparado: o chef comea fazendo seu sirigado com arroz de frutos do mar e, na hora em que o prato chega, seu pedido j era javali ao barolo. No d. Grandes sistemas so como o que talvez tenha falido a FoxMeyer: a encomenda custou US$35 milhes. Segundo o Standish Group, a taxa de sucesso para projetos acima de US$10 milhes, que tipicamente envolvem quinhentas ou mais pessoas por perodos de trs anos ou mais, estatisticamente zero! Para projetos de at US$750 mil, que tipicamente envolvem seis pessoas por seis meses, a taxa de sucesso 55%. Para projetos pequenos (microprojetos), que custam at US$250 mil e duram de trs a quatro semanas, taxas de sucesso de 70% podem ser esperadas depois de alguma prtica e h razes para se pensar que, havendo um processo to afinado quanto a cozinha dos melhores restaurantes, as taxas de sucesso possam chegar perto dos 100%. A receita do Standish Group - Chaos: a recipe for success (e de outros, como Donald Reifer) para o sucesso inclui envolvimento e apoio dos executivos e usurios, gerentes de projeto experientes, objetivos claros e escopo reduzido. Estes poucos itens, bem cuidados, seriam responsveis por 70% das chances de sucesso de projetos de software. A receita mais simples do que parece: gasta muito esforo, envolvimento de todas as pessoas-chave das instituies, educao contnua e implantao de mtodos e processos claros e efetivos. A mudana de longo prazo, mas para sempre e comea por quem contrata. Se for voc, comece por perguntar, da prxima vez, pelos mtodos e processos de quem voc vai contratar. Fonte: UM MUNDO FEITO (QUASE COMPLETAMENTE) DE SOFTWARE por Silvio Lemos Meira que professor titular de engenharia de software da Universidade Federal de Pernambuco e cientista-chefe do Centro de Estudos e Sistemas Avanados do Recife (Cesar). Pesquisa sobre o desenvolvimento de software e o panorama da TIC na atualidade O Standish Group com o seu Chaos Report 2009, nos permite examinar com andam o mundo dos projetos de TIC e podemos perceber que apesar das melhoras em relao ao perodo da crise do software, ainda no so boas. Com a finalidade de coletar e analisar a taxa de sucesso para projetos no setor de TI o relatrio Chaos, nos fornece um panorama do mercado. Abaixo est o grfico de 2009 e para entend-lo segue a explicao das legendas: Successful (com sucesso) - representa o % de projetos aprovados, isto , entregues no prazo, no oramento e com as funcionalidades requeridas pelo cliente atendidas; Challenged (com desafios) - representa os projetos que passaram do prazo, do oramento e incluram menos requisitos dos solicitados pelo cliente; e Failed (com falhas) - so os projetos que foram cancelados antes da concluso, nunca entregues ou mesmo nunca usados. Existem alguns crticas quanto os dados coletados, pois alguns alegam que s se mede oramento, prazo e escopo, no se

avaliando risco, qualidade e satisfao. Mas, mesmo assim esse relatrio uma das melhores referncia acompanhar a evoluo do desenvolvimento de projetos na rea de TIC. Figura 1 - Evoluo dos projetos

Fonte: Standish Group, CHAOS - 2009 Observar essas prximas figuras para ter uma idia em percentuais da situaes dos projetos de software comparando os dados de 2004 e 2009. Seguidos do quadro com a evoluo de TI em relao aos trs parmetros analisados: sucesso, desafio e falha, na ltima dcada. Figura 2 - Situao dos projetos 2004

Fonte: Standish Group, CHAOS - 2004 Figura 3 - Situao dos projetos 2009

Fonte: Standish Group, CHAOS - 2009 Quadro 1 - Evoluo dos projetos

Year 1994 Year 1996 Year 1998 Year 2000 Year 2002 Year 2004 Year 2006 Year 2009

Year 1994 Year 1996 Year 1998 Year 2000 Year 2002 Year 2004 Year 2006 Year 2009 Succe ssful 16% Challe nged 31% Failed 53% 27% 40% 33% 26% 28% 46% 28% 23% 49% 34% 15% 51% 29% 53% 18% 35% 19% 46% 32% 44% 24%

Fonte: Standish Group, CHAOS - 2009 Entendido o recado acima como era antes das preocupaes com os insucessos Figura 4 - O faz tudo Desenvolver sem um processo, baseado em uma metodologia, seja tradicional ou gil, um grande risco ou mesmo um desenvolvimento anti-profissional. Para ser mais acadmico um desenvolvimento ADHOC, isto , o desenvolvedor faz tudo e por demanda, sem planejamento. O sucesso nesse caso est normalmente relacionado ao fator SORTE. Para no ficar na dependncia desse fator fazer uso de um processo um bom comeo. Mas, por que desenvolver "sem qualidade" desenvolver Adhoc. Vamos primeiro entender esse termo. Adhoc uma expresso de origem latina, que pode ser traduzida literalmente como sendo "para esta finalidade". Na Engenharia de Software, o uso da expresso Adhoc serve para designar trabalhos de construo de software que no foram planejados para atendimento de uma demanda do usurio, sendo assim no se tendo uma planejamento, mas uma estimativa de de prazo e custo, que pode ser muito abaixo ou acima da realizada, j que conta com a experincia para fornecer esses valores e no com um planejamento e clculo da utilizao dos recursos. O CMMI nvel 1, faz referencia dessa expresso para designar modelos informais utilizados pelos desenvolvedores de software, no oferecendo uma linguagem padronizada para comunicao de idias, gerando dificuldade no compartilhamento dessas informaes entre os envolvidos. Resumindo, desenvolver Adhoc, faz-lo por demanda, sem planejamento. E se com planejamento j complicado se estar entre os projetos que possuem sucesso, imagine, se isso depende do fator sorte. Para um melhor entendimento do que normalmente acontece no desenvolvimento de software sem a preocupao com qualidade segue a figura abaixo: Figura 5 - Como normalmente um desenvolvimento Adhoc

Percebe-se que pela primeira imagem (como o cliente explicou) para a ltima imagem (o que o cliente realmente necessitava) existe uma grande diferena, e essa resultante de falha na COMUNICAO. Isso, esse componente vital para o sucesso no desenvolvimento de software. Para isso existe uma rea de pesquisa chamada de Engenharia de Requisitos. Sim, elicitar requisitos vital para o sucesso, isto , entender realmente o que o cliente deseja e poder atend-lo, no prazo e custo aceitveis um dos fatores de sucesso. Mas, isso no uma tarefa fcil. Ento o que um processo Adhoc? um processo imaturo! Isto : Processo imporvisado por desenvolvedores e gerentes; No rigorosamente seguido e o cumprimento no controlado; Dependente de pessoas; Viso do progresso e da qualidade deficientes; Prazos sobrepem satisfao do cliente e qualidade; Custos de manuteno so excessivos; e Qualidade difcil de se prever. Segundo Tom DeMarco. "No se consegue controlar o que no se consegue medir". Talvez fique mais claro o que esse grande pesquisador de gesto de projetos e autor de vrias obras na rea, quis dizer, que sem planejamento, no se consegue ter parmetros (medidas) para acompanhar, e assim, no se consegue verificar, se o que foi planejado, foi realizado. E pior no se tem gerencia sobre sua execuo, resultando em respostas tpicas a perguntas frequentes em desenvolvimento: Como est o projeto? Andando! A atividade que voc est responsvel, como est? Estou fazendo! Quando fica pronta? Estou terminado! J sabe, usar o gerndio, sinnimo de falta de planejamento ;) O que fazer para se ter mais chances de sucesso nos projetos de TIC? Planejar o primeiro grande passo. Esse planejamento passa por definir uma metodologia e escolher um processo maduro e aceito pelo mercado. Mas, isso s o primeiro passo. Para entender melhor, o por que s o primeiro passo, segue um artigo publicado por Silvio Meira. Leia muitssimo importante. Segue o link: Um Mundo Feito (quase completamente) de Software. Ento planejar no tudo, mas um dos pontos necessrios para aumentar as chances de sucesso. Outro fazer uma boa anlise. E o que fazer anlise? Um exemplo que gosto de usar nas minhas aulas fazer a analogia a um atendimento mdico. Vamos l. Imagine que existe um indivduo com uma forte dor de cabea. Dor essa que persiste a muito tempo, tanto tempo que at j se esqueceu quando comeou. E nesse perodo esse nosso indivduo, j fez de tudo para resolv-la se consultar um especialista. J tomou remdio por conta prpria. J fez simpatias. Mas, nada disso surtiu efeito, e o pior cada vez a dor de cabea aumentava. Assim, um dia. Sem mais condies de continuar a vida com essa no desejada acompanhante, ele foi ao mdico. Existe dois tipos de mdicos (especialistas). Um ruim e outro bom. No nosso exemplo, o primeiro a ser consultado foi o ruim. Claro nosso paciente no sabia, mas o foi. Por qu? Obvio, ele era o mais barato :) Esse, por sua vez, quando atendeu nosso fictcio paciente, nem mesmo levantou o rosto para v-lo. Estava escrevendo e assim continuo. Caso essa descrio se assemelhe a algo conhecido. :) mera coincidncia. Escrevendo estava, escrevendo continuou, sabe-se l o qu. E perguntou:

- Qual o seu problema? (especialista) - Dr. Estou com uma forte dor de cabea, a tanto tempo que nem me lembro, quando comeou. (paciente) - Humm. Trabalha muito? (especialista) - Sim, como todo bom brasileiro, que tem que pagar as contas! (paciente) - Hummmm. Extresse. Tome esse remdio! (especialista) - Vou ficar bom? (paciente) - Sim! (especialista) Bom, claro que no ficou e sim piorou. Ento, nosso paciente foi para o segundo (o bom). Claro, mais caro. Mas, como se diz "as vezes o barato, sai mais caro". E l chegando veja a diferena: - Qual o seu problema? (especialista) - Dr. Estou com uma forte dor de cabea, a tanto tempo que nem me lembro, quando comeou. (paciente) - E o que j fez para tentar resolv-la? (especialista) - D tudo. O Sr. nem vai querer saber. (paciente) - Bom, infelizmente vou. Para ter uma exata proporo do que j aconteceu! (especialista) - Ok. Bl-bl-bl. (paciente) - Agora, conhecendo o seu histrico, preciso solicitar alguns exames! (especialista) - Ok. Quais?. (paciente) - Sangue, como na cabea - uma ressonncia ... ! (especialista) Tempos depois: a) feitos os exames; b) entregue-os; c) solicitados outros; d) entregues; e) dias solicitados para realizar anlises; e f) solicitaes de parecer de outros especialistas. claro o paciente, estava irritado, pois ainda estava com a dor de cabea, mas agora, tambm estava todo furado, das vrias amostras de sangue, e claro, indignado com a demora. Mas, o dia marcado para saber o resultado, o mdico lhe diz: - O que o Dr. pode fazer para resolver o meu problema da dor de cabea? (paciente) - Sr. a sua dor de cabea apenas o sintoma, o efeito do seu problema! (especialista) - Humm. (paciente) - O Sr. possui um tumor na cabea! Esse seu problema! (especialista) - HUMMMM - Me f! (paciente) - No! Existe soluo. (especialista) - Hum. (paciente) - So trs as alternativas: (especialista) 1a. cirurgia, cara, mas cura rpida; 2a. quimioterapia, no to caro, mas mais lenta; e 3a. remdio para dor de cabea, muito barato, mas o Sr. vai ter uma vida curta! - Caramba?. (paciente) - A deciso sua! (especialista) Essa pequena histria, mostra a importncia dos exames, das anlises e das possveis solues e consequncias. Agora, substitua o paciente por cliente, o especialista pelo analista, a dor de cabea pela falta de sucesso na empreitada, o sintoma pelo efeito, a causa pelo fator, os exames pelas anlises, a soluo pelo projeto, as alternativas pelas propostas, e pronto temos o mesmo quadro para projetos de TIC. Inclusive com as mesmas consequencias, pois caso a opo escolhida seja a trs, enquando a possibilidade de falncia do primeiro exemplo de uma pessoa fsica a do segundo de uma pessoa jurdicas, mas as consequencias so to desastrosas quanto a primeira. isso. O que fazer para aumentar as chances de sucesso? Planejar, analisar e projetar solues. Primeira atividade clique aqui para responder as questes da primeira aula ATV1 e clique aqui para ver o resumo das respostas da primeira atividade Resostas ATV1. Principais Referncias The Standish Group, CHAOS. Ian Sommerville. Engenharia de Software - 8 Edio, 2007. Biografias

Ian Sommerville, ingls nascido em 1951 professor titular de engenharia de software na Universidade de St. Andrews na Esccia. Destacado pesquisador no campo da engenharia de sistemas, segurana e informtica social. Saber mais. Links http://www.standishgroup.com/ http://www1.standishgroup.com/newsroom/chaos_2009.php e-books SOMMERVILLE, Ian. Engenharia de Software. 8o.Edio. So Paulo: Pearson, 2007.

AULA 02 - Modelos de Desenvolvimento

Metodologias, processos, prticas e tcnicas. Bom, antes de mais nada, vamos saber as diferenas entre esses termos que muitos confundem, e acabam achando que so sinnimos. Metodologia um conjunto de prticas, e prticas so aes estruturadas que podem ser repetidas durante um processo de desenvolvimento de software. Sendo uma metodologia um conjunto, ela envolve vrias prticas como gerenciamento de projetos, engenharia de requisitos, anlise e modelagem, codificao e testes. Alm das mais diversas gerencia, como: de configurao, ambiente, risco, qualidade, aquisio, etc. Ento o que um processo ou modelo? Apesar de se confundirem, no so, a mesma coisa. Podemos dizer que processo de desenvolvimento de software um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto de software. Realizando o mais corretamente possvel as etapas de uma construo de software. Definindo tcnica temos. Um procedimento ou mesmo um conjunto de procedimentos, que tem como objetivo alcanar um determinado resultado. E segundo os estudiosos do assunto, se caracteriza por ser consciente, reflexiva e inventiva. Em uma anlise mais bsica, teramos. Metodologia como um conjunto de tcnicas (prticas) que repetidas sempre tendem a chegar ao mesmo resultado esperado. E um processo , a forma de organizar essas tcnicas, onde se conhece quem faz, como faz, e quando faz. Nos dias atuais, normalmente se classificam as metodologias em tradicionais ou pesadas e geis. Mas, como tudo comeou? Breve histria da evoluo das metodologias/processos Figura 6 - Evoluo das metodologias/processos Como se pode observa nessa figura entre as dcadas de 50 e 80, o que existia era a chamada anlise estruturada que posteriormente evoluiu para anlise essencial. Sendo a primeira forma organizada de desenvolvimento, focada na qualidade da construo de software, naturalmente muitos problemas eram inerentes a essa forma, mas inegavelmente, era sim, a melhor forma de se construir uma aplicao. Mas, o grande problema desse modelo, consistia na grande quantidade de simbologias para as diversas fases de construo. Explicando melhor, um analista fazia fluxogramas para retratar a soluo de um problema e uma srie de outros diagrama, a exemplificar, diagrama de contexto, macro-diagrama, diagrama de fluxo de dados, e por a vai. O grande problema que para banco de dados, existia outra diagramao, o modelo de entidade relacionamento, e para desenvolvimento, a codificao propriamente dita, no se tinha uma simbologia padro. Vale salientar, que nesse perodo, vrias estudiosos passaram a desenvolver suas prprias simbologias, criando verdadeiros ncleos, dificultando o entendimento entre os profissionais de escolas diferentes. Esse perodo, onde se encontravam as linguagem de estruturadas e textuais, como cobol, fortran, pascal, clipper e

Esse perodo, onde se encontravam as linguagem de estruturadas e textuais, como cobol, fortran, pascal, clipper e tantas outras, havia uma lacuna muito grande entre os analista de sistemas e os programadores. entre as dcadas de 80 e 90 que se comea a se tornar comum o uso da orientao a objetos. Esse novo paradigma de desenvolvimento, surge no mundo profissional quase em paralelo com os sistemas multitarefas, que viriam a substituir os monotarefas com suas linguagens estruturadas e textuais. Essa nova forma de programar veio com a orientao a eventos e interface grfica a GUI. Ento, defini-se novos conceitos como classe, objeto, herana, encapsulamento e polimorfismo. Assim, os estudiosos desse tema, comeam a construir suas simbologias, correndo o risco de surgirem novos ncleos e escolas independentes que sem dvida, iriam complicar ainda mais o entendimento dessa rdua tarefa que construir software. Figura 7 - Surgimento da UML Mas, em meados de 90, A SEI cria um grupo chamado OMG, que tem como responsabilidade evitar que esses ncleos surgissem. Assim, nessa poca os principais estudiosos do tema foram convidados para participar desse grupo. Esses nomes so: Grady Booch que manifiesta a necessidade de unificar critrios, James Rumbaugh se une a Booch em outubro de 1994 e elaboram a verso 0.8 do Unified Method e por fim Ivar Jacobson que completa o trio. Esses trs nomes passam a ser considerados os pais da orientao a objetos, definindo os padres da Linguagem de Modelagem Unificada, que na sua sigla em ingls conhecida como UML. Passando a ser o modelo aceito como padro pela OMT e assim pela SEI e por consequencia pelo mercado. Ok, com a simbologia padronizada, evitando aquela chuva de diagrama que variavam de escola para escola, precisavase agora definir um padro de desenvolvimento para esse novo paradigma. Mas, padres j existiam e vamos falar deles. Figura 8 - Modelo Cascata

O modelo cascata uma forma seqencial de desenvolvimento de software, onde o ciclo de vida de um projeto comea pelos requisitos seguindo pelas especificaes e modelagem, passando pela implementao e testes, at chegar na implantao e manuteno. O problema desse modelo que todas essas etapas so executadas, uma aps a outra, com a observao de que cada etapa de ser exaurida antes de passa para a prxima, ocasionando um grande lapso de tempo entre anlise, projeto e implantao. Essa distancia entre as fases macros geram inevitavelmente problemas nos requisitos, j que esses podem mudar pela prpria natureza do negcio ou pelo problema mais comum, a comunicao entre os envolvidos. Algumas caractersticas desse modelo so: Execuo sequencial das atividades; Levantamento de todos os requisitos no inicio do projeto (algo que a experincia mostrou ser muito difcil); Talvez a caracterstica mais negativa desse modelo, seja a de que o usurio envolvido apenas no inicio do projeto e na entrega do produto final, aumentando exponencialmente as chances de falha durante o projeto; e as mudanas nos requisitos no so bem vistas, pois gera retrabalho e conseqentemente aumento dos custos. Mas, mudana de requisitos inevitvel na construo de qualquer software, por mais estvel que seja. Figura 9 - Modelo Prototipao Uma forma de lidar com a impacincia dos usurios no modelo cascata, foi a criao ou melhor, a adaptao de uma tcnica ao modelo que rendeu a denominao de prototipao e assim, surgia um novo modelo. Que na verdade era o modelo em cascata, ma servido da tcnica de fazer prottipos para que o cliente durante o processo, tivesse condies de acompanhar o andamento, visualizando como o software ficaria. Mas, o problema desse modelo, era que, sua premissa dizia que o prottipo deveria ser descartvel, isto , apresentado ao cliente, este faria as observaes, e no local de desenvolvimento (fbrica de software) esse prottipo deveria ser descartado e o

(fbrica de software) esse prottipo deveria ser descartado e o desenvolvimento, seria continuado no modelo real. Bom, pura iluso, pois, o que os desenvolvedores faziam era continuar evoluindo o prottipo que virava o entregvel. Alm dos problemas j citados acima, esses persistiam, j que a forma de construir o software no mudara muito. Figura 10 - Modelo Espiral At que surge o modelo espiral, isto , voc faz os levantamentos dos requisitos de software. Importante, no de todo o projeto, mas do que foi planejado, isto , em etapas, normalmente do que mais relevante para o que menos. Porm, dependo muito das necessidades do projeto. Depois desse levantamento, faz-se a diagramao do que foi requisitado, codifica-se, testase e implanta-se. Pronto. Nesse momento o cliente interage novamente com o software, fazendo que o lapso de tempo seja bem menor, muito menor. O que ao longo do processo de amadurecimento dos modelos, viu-se ser muito proveitoso para o sistema. Afinal de contas, para o cliente que se faz o software. Nesse momento, existem ajustes a serem combinados, e nova repetio do fluxo se faz, e se far tantas vezes se faa necessrio ou se tenha planejado. Esse modelo se mostrou muito mais prximo as reais necessidades de um bom desenvolvimento, e dele surge o que efetivamente ganho o mercado. Mas, por que esse no se consolidou. Simples, no se fazia idia que permitir a interao com o cliente entre as fases de desenvolvimento daria tanto problema :) assim, foi necessrio planejar essa interao, surgindo as iteraes. Figura 11 - Modelo Iterativo e Incremental

O modelo iterativo e incremental, consiste em fazer o desenvolvimento do software no modelo espiral, mas sabendo que em cada iterao, isto , nova rodada de fases, talvez se tenha que corrigir falhas das rodadas anteriores, alm de implementar as novas funcionalidades da rodada corrente. Simples, direto e objetivo. Esse modelo, se mostrou o mais prximo da realidade do desenvolvimento de projetos de software. Se tornando a base para uma grande gama de processos hoje vigentes. Figura 12 - Processo RUP De todos os processo criados o Rational Unified Process (RUP), sem dvida um dos mais famosos. Esse modelo, criado nos "primordios" da UML, trs todas as atividades, os papis, os artefatos, e os fluxos de trabalhos, que se deve ter em um desenvolvimento pesado de software. Isto , ele prev praticamente tudo que se deve fazer. E se tornou uma referncia de mercado. Sendo "vendido" como um framework, que deve ser adaptado para a realidade do projeto em desenvolvimento. Bom, ai que comeam os problemas. Para projetos de mdio e grande porte excelente. Se existe prazo e custo aceitveis para a contratao de mo de obra qualificada, e necessidade de controle de toda a produo. Esse o modelo. Mas, mesmo ele sendo declarado pelo sua fabricando Rational,

mesmo ele sendo declarado pelo sua fabricando Rational, hoje IBM, como "customizvel" para projetos de pequeno porte. O conhecimento desse processo, a experincia do "customizador" e as restries oramentrias e de prazo so complicadssimos para sua adoo. Mas, por um perodo de tempo, esse foi o processo utilizado para qualquer empresa de TIC que deseja-se construir algo com qualidade. At que grupos de pensadores, comearam a discutir se o uso desses tipos de processos, se justificavam para qualquer tipo de projeto de software. Nesse ponto entraremos na nossa prxima aula - as metodologias geis, j que os processos que passaram a ser chamados de pesados, receberam a denominao de metodologias tradicionais ou mesmo pesadas. Segunda atividade dessa aula, segue um link que na minha opinio um dos melhores tutoriais de RUP. Clique nesse link wthreex e navegue no processo. Veja quais so as 4 fases, as 9 disciplinas, o que compem as iteraes, quais so os papis em cada uma, os artefatos que devem ser gerados, as entradas e sadas, e quais os fluxos de trabalho. Principais Referncias Ian Sommerville. Engenharia de Software - 8 Edio, 2007. James Rumbaugh; Ivar Jacobson; Grady Booch. UML: Guia do Usurio - 2006. Biografias James Rumbaugh Bacharel em Fsica pelo MIT, possui mestrado em Astronomia pela Caltech, e Ph.D. em Cincia da Computao tambm pelo MIT. Trabalhou na Digital Equipment Corporation (DEC), como cientista. Foi um dos lderes na criao da OMT e em 1994 se juntou a Rational Software, e junto com Ivar Jacobson e Booch de Grady desenvolveram a Unified Modeling Language (UML). Mais tarde, eles fundiram as suas metodologias de desenvolvimento de software, OMT, OOSE e Booch em um nico processo batizado de Rational Unified Process (RUP). Saber mais.

Links http://www.sei.cmu.edu/ http://www.computer.org/portal/web/swebok http://www-01.ibm.com/software/awdtools/rup/ http://www.wthreex.com/rup/portugues/index.htm e-Books RUMBAUGH, James; JACOBSON, Ivar; BOOCH Grady. UML: Guia do Usurio. So Paulo: Campus, 2006.

AULA 03 - Engenharia de Requisitos

Tudo comea com o entendimento do problema Depois das explicaes das aulas 01 e 02, podemos dizer que, anlise identificar o real problema do cliente, e o projeto propor sua soluo. Mas, como entender o verdadeiro problema do cliente? A entramos na gesto de requisitos ou podemos chamar de engenharia de requisitos. Como visto anteriormente na metodologia tradicional, o processo RUP, define quatro fases, as quais so: concepo, elaborao, construo e transio. Em todas as quatro sempre haver algum esforo no entendimento das necessidades do cliente. J que, negcios mudam, ou pela sua prpria natureza, ou por falta de entendimento, ou por falta de detalhamento, at mesmo por todas elas juntas. Mas, o maior esforo no entendimento das necessidades do cliente, na grande maioria dos casos, ocorrer nas duas primeiras fases. Isso lgico, j que na primeira, estamos tentando entender o negcio, e na segunda levantando as necessidades do cliente, e essas, objetivando esmiuar ao mximo. Agora, independente da fase, se faz crucial para o sucesso do sistema, o entendimento do problema, para que se atinja o objetivo desejado, que obter um produto de software de melhor qualidade e que satisfaa real necessidade do cliente, dentro de um prazo e oramento adequados. Assim, nasce a Engenharia de Requisitos, que tem como premissa, conhecer todas as atividades usadas para a produo da documentao necessria ao entendimento do problema, como tambm a manuteno desses no decorrer do projeto.

problema, como tambm a manuteno desses no decorrer do projeto. Mas, o que exatamente um requisito? Podemos entender requisito como uma funo, restrio ou propriedade que deve ser fornecida, encontrada ou atendida para satisfazer s necessidades do usurio do sistema, descrevendo um servio ou uma limitao. Outra forma de definir requisito a descrio de uma condio ou capacidade necessitada por um usurio para resolver um problema ou alcanar um objetivo. Em outras palavras, o que o sistema deve fazer para implementar uma necessidade de automao requerida pela soluo. Desde as necessidades bsicas do cliente, premissas e restries obtidas na fase de levantamento do projeto at as condies de negcio explicitadas no contrato com o fornecedor da soluo. Compreende um conjunto de definies que descreve como o sistema deve ser construdo e testado, requisitos funcionais e no-funcionais, caractersticas operacionais e especificaes tcnicas, enfim, tudo o que o sistema tem que ter para atender plenamente ao propsito para o qual foi criado. Segundo o pesquisador Antnio Soares, a engenharia de requisitos um processo baseado em quatro atividades, as quais so: Validao, Identificao; Anlise; e Especificao. Mas, existe uma quinta atividade, inerente a qualquer processo de desenvolvimento, a de manuteno, seja ela corretiva ou evolutiva, e essa atividade recebe o nome na engenharia de requisitos de gesto de mudanas ou no ingls changed request. Ser que vivel fazer o levantamento de requisitos? Agora, como encontr-los? Bom, em primeiro lugar uma boa prtica, realizar antes de qualquer coisa um estudo de viabilidade que, a partir das restries do projeto, pode-se verifica se ou no interessante fazer a identificao dos requisitos. Mas, o que um estudo de viabilidade? a verificao da real necessidade de se levantar os requisitos, j que essa tarefa no bsica, e pode demandar muito tempo. Imagine que depois de todo o trabalho de elicitao realizado, verifica-se que esse no era necessrio. Assim, com esse estudo realizado, pode-se verificar se em relao a tecnologia e a estrutura organizacional, o projeto vivel. Uma tcnica usada para verificar a viabilidade do projeto , realizar reunies e/ou entrevistas, com aos stakeholderes do projeto, para obter resposta s seguintes questes: O projeto proposto contribui para os objetivos da organizao? Considerando as restries tecnolgicas, econmicas, polticas, ambientais, recursos e de prazo, o projeto pode ser levado adiante? Se existe necessidade de integrao entre diferentes sistemas, essa possvel? Caso o novo projeto no for construdo, quais sero as conseqncias e o que se deve fazer? Baseado nos efeitos percebidos pelo cliente. Quais so os problemas? Como esses problemas podem ser resolvidos? Haver colaborao e se sim de que forma? Com essas questes respondidas, pode-se ter uma deciso mais p no cho, para prosseguir com o levantamento dos requisitos. Aps esse levantamento, deve-se produzir um relatrio que ir determinar a continuao ou no do desenvolvimento do projeto. Que tal como exerccio fazer uma entrevista com algum e montar um documento com as informaes coletadas e a partir delas responder as questes acima, para verificar a viabilidade do projeto. Caso o estudo de viabilidade, mostre que vivel o desenvolvimento do projeto, deve-se ento iniciar a identificao dos requisitos de software. E a primeira atividade deve ser o entendimento do domnio da aplicao, isto , compreender o negcio que se pretende construir uma soluo. Esse entendimento vital para melhorar a comunicao entre os analistas e as partes interessadas. Um dos passos identificar os stakeholders, isto , todos os envolvidos no projeto, o outro fazer um estudo do assunto a ser desenvolvido. Depois disso, iremos para o levantamento dos requisitos funcionais e no-funcionais. Que tal agora, fazer uma pesquisa na Internet ou em livros. Melhor na Web com o Professor Google. E criar um glossrio do negcio, isto , um documento com os termos e jarges do negcio estudado. Se vivel fazer o levantamento de requisitos, como faz-lo? A prxima fase a chamada identificao dos requisitos. baseada em questes do tipo. O cliente no sabe o verdadeiro problema, pois s tem conhecimento dos efeitos dele.Como conseqncia os requisitos elicitados, podem

no ser relevantes ou mesmo reais, para a soluo do problema. Caso existam vrios stakeholders, esses podem expressar suas necessidades, em forma de requisitos diferentes, mas com a mesma finalidade. Ento, quais so as tcnicas para levantamento de requisitos, para minimizar esses problemas? Existem diversas tcnicas de identificao de requisitos, e que devem ser usadas de acordo com a necessidade. Um delas o uso de entrevistas e questionrios. Nessa, se dever ter domnio sobre o assunto, para que se possa inferir nas respostas do stakeholder. E importante que o analista d espao ao entrevistado para que o mesmo possa expor as suas ideias. No o interrompa desnecessariamente. Outro fator importante no uso dessa tcnica verificar a predisposio do entrevistado, pois caso, a atividade dele esteja sendo afetada pelo novo sistema, isso pode ocasionar dificuldades na obteno das informaes. Sempre construir um plano para realizar a entrevista, pois na ausncia deste, pode se perder muito tempo com itens no relevantes ao assunto em questo. Outra tcnica o uso de um workshop para requisitos, que consiste em realizar uma reunio na qual devem fazer parte o maior nmero de stakeholders possvel. Nessa tcnica deve-se fazer uso de momentos de descontrao, para possibilitar um clima mais propcio e ao mesmo tempo dinamizar o trabalho. Deve-se, quando possvel fazer uso de facilitador cujo papel coordenar as atividades a serem realizadas. No final do workshop, deve-se produzir um relatrio que reflita os requisitos e decises tomadas na mesma. Mais uma tcnica, que pode ser usada como uma atividades, nas tcnicas anteriores, a chamada tempestade de idias ou no seu termo em ingls mais conhecido tecnicamente, o brainstorming. Que tem a finalidade de obter o maior nmero de ideias numa pequena quantidade de tempo. No final do brainstorming, deve-se produzir um relatrio que reflita as ideias obtidas. Cenrios, uma outra tcnica muito interessante, pois , uma forma de levar os stakeholders a imaginarem o comportamento do software. Assim, os futuros usurios podem interagir com o software, mesmo ele ainda no existindo, aumentando as possibilidades de requisitos obtidos. E para que essa tcnica fique mais eficiente, os seguintes elementos devem ser considerados: O estado inicial do software; a sequncia de eventos que devem ocorrer; Quais excees podem ocorrer na execuo dos eventos; Quais tratamentos devem ser dados quando as excees ocorrerem; Quais as aes iro acontecer; e Qual o estado final do software na termino do cenrio. Mas, a tcnica mais usada a prototipagem, que consistem em criar um rascunho do software, baseando-se nos requisitos iniciais, e com esse, melhorar a comunicao entre os stakeholders, com o intuito de obter mais requisitos. Neste tipo de abordagem apenas algumas funcionalidades so desenvolvidas, j que a finalidade desse ser descartado, pois no deve ser considerado o produto final. Apesar de em muitos casos o prottipo acaba sendo evoludo e passando a se tornar o produto final, sendo chamada essa tcnica de prototipagem-evoluda. A outra tcnica o estudo etnogrfico. Nessa se analisa o componente social das atividades desempenhadas. Ela se baseia na observao direta das atividades realizadas durante um perodo de trabalho de um stakeholder, possibilitando encontrar requisitos. Esta observao pode ser realizada atravs de registros de udio/vdeo. Bom, tenho os requisitos elicitados. E agora? Vamos analisar! A terceira fase a de anlise, que ocorre aps a identificao dos requisitos, e consiste em classificar os requisitos em mdulos para facilitar a visualizao dos mesmos em um viso macro, que na anlise estruturada era chamado de macro-diagrama. Outro ponto importantssimo dessa fase a resoluo dos conflitos, que inevitavelmente ocorrem dadas a variedade de documentos produzidos na fase de identificao de requisitos. O prximo a priorizao, que consiste na atribuio de um nvel a cada requisito, onde normalmente se atribui os valores alta, mdia e baixa prioridade ou se usa essencial, importante e recomendvel, se pode usar tambm os valores essencial, mandatrio e importante. Agora, como obter essa priorizao? A melhor forma fazer uso de mtricas, um bom exemplo a Anlise de Ponto de Funo. Mas, existem outras tcnicas, tipo Wide-band delphi, que mais leve e rpida. Independente, da tcnica, o importante classificar, para identificarmos o que mais ou menos relevante para o cliente. Depois de modularizar e classificar, importantssima, a homologao, para que os envolvidos tenham cincia e forneam o de acordo. Para que a completude dos requisitos, sua consistncia e validade sejam aceitos por todos. importante salientar que essas fases no so independentes, j que uma informao obtida numa fase entrada para outra e assim por diante. A identificao e anlise de requisitos so processos iterativos que se iniciam como o entendimento do domnio da aplicao e culminam com a homologao dos requisitos, permitindo que se tenha o melhor entendimento possvel do sistema.

melhor entendimento possvel do sistema. Mas, claro, existem muitas dificuldades nesse processo e essas so de diversas naturezas, como fatores externos, do tipo legislao ou poltica scio-econmica, que podem influenciar nos requisitos. A decorrente de interesses particulares, que se advindo de um envolvido com poder de deciso, pode exigir requisitos especficos que sirvam aos seus interesses e no aos da aplicao, que tem como objetivo atender a organizao. Outro fator quando um envolvido com poder de deciso, tenta forar o seu ponto de vista em detrimento dos demais interessados. Existe tambm o ambiente, seja ele econmico e/ou organizacional, onde a anlise realizada possui fatores dinmicos, tornando os requisitos suscetveis a mudana. Bom, tenho os requisitos elicitados. E agora? Vamos analisar! Seguindo temos, a fase de negociao delicada e deve-se ter muito cuidado para que ocorra sem problemas. Para isso existe uma tcnica, que deve ser aplicada aos que sero envolvidos nesse processo. Essa consiste em levantar as seguintes questes. Os envolvidos sabem: Lidar com ataques pessoais, evitando-os sempre que possvel, remetendo a sua resoluo para mais tarde, fora de reunio, de preferncia nunca tomando partidos; Fomentar a justificao das posies negativas tomadas pelos intervenientes na negociao; Salientar e procurar encontrar os benefcios que uma soluo apresenta para todos os envolvidos; e Relaxar restries, quando se torna bvio que as actuais no conseguem levar a um consenso.

A fase de especificao e documentao, se d no final, e consiste de descrever baseado nos padres reconhecidos pelo mercado, os requisitos especificados. Mas, nessa etapa deve-se classificar esses requisitos em duas categorias. A dos funcionais, e a dos no-funcionais, que so normalmente representados pela siglas RF e RNF, respectivamente. Os requisitos funcionais servem para descrever as funcionalidades que se espera que o sistema tenha, isto , aquilo que o usurio espera que o sistema oferea, atendendo aos objetivos requisitados. Esses requisitos especificam aes que um sistema deve ser capaz de executar, sem levar em considerao restries fsicas, portanto, especificam o comportamento de entrada e sada de um sistema. Os requisitos no-funcionais servem como restries e esto relacionados ao uso do sistema em termos de desempenho, usabilidade, confiabilidade, segurana, disponibilidade, manutenibilidade, tecnologias envolvidas, utilidade, suporte e escalabilidade. Normalmente no so obtidas com o usurio, j que so caractersticas mnimas de um software de qualidade, ficando a cargo do desenvolvedor optar por atender esses requisitos. Segue alguns exemplos: Tempo de resposta do sistema no deve ultrapassar 15 segundos; Software deve ser operacionalizado no sistema Windows; e O banco de dados usado dever ser o Oracle. importante entender que os requisitos no-funcionais so crticos para o sucesso do software e esto diretamente relacionados com a satisfao dos usurios. Devido a essa importncia, alguns requisitos funcionais podem ser sacrificados para atender s restries impostas pelos requisitos no-funcionais. Em um processo bem organizado, pode-se gerar diferentes tipos de documentos de especificao de software, os quais so: Especificao de requisitos do utilizador; Especificao de requisitos do sistema; e Especificao do design da aplicao. Essa organizao permite que determinados tipos de especificao que serve para comunicar apenas um determinado tipo de informao, siga apenas para os interessados por ela, evitando assim, informao em demasia. Por exemplo, enquanto os requisitos do utilizador informam apenas a abordagem de alto nvel das funcionalidades do sistema e suas restries, usando para isso uma linguagem natural e eventualmente diagramas, os requisitos do sistema descrevem cada requisito com todos os detalhes introduzindo conceitos relativos arquitetura do sistema, utilizando tambm diagramas de casos de uso para isso. Seguem alguns cuidados para produo dessas documentaes de requisitos: Do utilizador. Destinado aos usurios de alto nvel. Deve se escrito com linguagem natural, com poucos formulrios e diagramas simples. As dificuldades na sua produo so a ambigidade, confuso e agrupamento de requisitos. Tcnicas para sua produo so: Usar o mesmo formato em todos os requisitos; Distinguir claramente entre comportamentos esperados e desejveis do sistema atravs do uso de expresses como "O sistema permitir criar (...)" ou "Dever ser possvel criar (...)" respectivamente; Usar formatao de texto para salientar determinados aspectos do documento; e Evitar usar termos demasiado tcnicos ou fora do mbito do sistema, identificando-os e definindo-os de uma forma clara quando for absolutamente necessrio us-los. Do sistema. Destinado aos usurios mais tcnicos. Deve conter uma descrio detalhada dos requisitos correspondentes ao uso, usando terminologia tcnica quando preciso. Dificuldades: As mesmas palavras podem, de

correspondentes ao uso, usando terminologia tcnica quando preciso. Dificuldades: As mesmas palavras podem, de acordo com a interpretao de cada pessoa, designar conceitos diferentes; e O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada pessoa tenha de saber quando que descries diferentes se referem ou no a requisitos diferentes. Do Design. Destinado aos desenvolvedores do sistema. Neste esto definidos os detalhes, em um nvel totalmente tcnico, acerca da implementao do sistema e sua arquitetura. A partir deste documento, um novo recurso que entre na equipe de desenvolvimento no meio do projeto, poder facilmente entend-lo. Compreendendo a forma de implementao. Da Especificao de Requisitos ou Documento de Requisitos de Sistema (DRS). Pode ser entendido como uma descrio formal e oficial onde descrita e comunicada os requisitos a todos os envolvidos no processo de desenvolvimento de software os stakeholders. Sendo basicamente composto dos servios e funes que o sistema deve prover; As limitaes sobre as quais o sistema deve operar; Definies de outros sistemas com os quais o sistema deve integrar; Limitaes no processo usado para desenvolver o sistema; e Descries sobre o hardware no qual o sistema ir executar. Esse um documento completo, usado como declarao oficial dos requisitos do sistema. Este documento, normalmente conhecido na sua denominao em ingls Software Requirements Specification ou SRS, inclui uma combinao dos requisitos do utilizador e do sistema e tem diferentes utilidades, as quais so: Clientes, confirmar a completude dos requisitos e propor alteraes; Gestores, oramentar o sistema e planejar o processo de desenvolvimento; Engenheiros de software, compreender o sistema a desenvolver; Engenheiros de testes, desenvolver testes para validar o cumprimento dos requisitos; e Arquitetos de software, compreender o sistema e a ligao entre as suas partes. Para melhor entendimento desse documento, segue o template do mesmo, usado pelo RUP. Existe uma tcnica para produo do documento de requisitos, e essa consiste em demonstrar que o documento produzido corresponde, de fato, ao sistema que o cliente deseja. A validao especialmente importante em sistemas de grandes dimenses uma vez que erros encontrados demasiado tarde, durante o desenvolvimento ou j depois de o sistema estar sendo usado produzem um efeito desastroso, tanto a nvel financeiro, como de credibilidade. Segundo um estudo do Standish Group, quanto maior o software, maior a possibilidade do insucesso. Veja o grfico. Figura 13 - Percentual de sucesso por tamanho do software

Outro problema srio, quando se descobre uma falha. Observe o grfico abaixo e veja qual o incremento no custo de produo de um software, quando se detecta uma falha. Percebe-se que quanto mais tardio for encontrado essa falha muito maior ser o seu custo de correo. Figura 14 - Custo de correo por tempo de identificao do erro

Os estudos comprovam que, a maior parte dos problemas os de maior impacto negativo e os mais onerosos tm origem nas etapas iniciais do desenvolvimento de software. Justamente nas etapas de especificao dos requisitos, onde as principais atividades so definidas e onde os requisitos do produto devem ser identificados e mapeados com objetividade e clareza. Podemos dizer que as principais causas para o fracasso dos projetos de software so: especificao de requisitos mal formulada e alteraes constantes nos requisitos. Por serem atividades bases do processo de desenvolvimento de software as falhas cometidas nas atividades de definio e validao de requisitos iro originar documentos de requisitos inconsistentes afetando as etapas seguintes de projeto, implementao e testes e gerando produtos de softwares de baixa qualidade. Veja essa outra figura baseado em um estudo da Standish Group, sobre as principais originadores de falhas. Figura 15 - Percentual de insero de erros

Para minimizar ou evitar isso, existe uma tcnica que consiste em fazer um checklist, avaliando os seguintes aspectos: Validade, se as especificaes levantadas so aceitas por todos os envolvidos; Consistncia, se existem conflitos entre os requisitos identificados; Compreensibilidade, se so fceis de serem compreendidos; Ambiguidade, se os requisitos esto em uma forma inequvoca pelas partes interessadas; Completude, se todas as funcionalidades pretendidas fazem parte da especificao do sistema; Realismo, se as restries do projeto, sejam tecnolgicas, financeiras e/ou temporais, so reais; Verificabilidade, serve para evitar futuras discordncias quanto concretizao dos requisitos; Rastreabilidade, se a origem dos requisitos foi identificado, isso , importantssimo para facilitar a gesto futura dos requisitos; e Conformidade com normas, se as normas foram usadas ao longo de todo o documento. Para completar, a engenharia de requisitos to importante, que fazer a gesto de requisitos, crucial para fornecer qualidade na produo do software. A sua gesto torna o trabalho rduo de levantar requisitos em uma atividade mais segura, j que o surgimento de requisitos em um projeto de software muito natural, devido a vrios motivos. Podemos citar, a necessidade de resoluo de conflitos entre requisitos resulta num compromisso que procura equilibrar as necessidades das diferentes partes interessadas, gerando novos requisitos. Outro fator a orientao do negcio que pode-se alterar, tipo, nova legislao ou regulamentao pode comprometer alguns dos requisitos do sistema. Alteraes a nvel tecnolgico podem surgir na organizao, afetando particularmente, no caso de alteraes

sistema. Alteraes a nvel tecnolgico podem surgir na organizao, afetando particularmente, no caso de alteraes de hardware, os requisitos no-funcionais. Podem surgir novos sistemas que precisem de suporte, em nvel de interao, por parte do sistema implementado, e toda uma srie de alteraes imprevisveis pode surgir fazendo com que o sistema tenha de se adaptar a todos esses novos requisitos. Existem requisitos que, tipicamente, so mais volteis ou melhor dizendo, mais dinmicos, do que outros, como por exemplo requisitos que dependam da entidade poltica governante num dado momento, enquanto que outros so relativamente estveis, os que se referem natureza do negcio propriamente dita. Na prtica, a gesto de requisitos acaba por coincidir com o incio de novos processos de engenharia de requisitos, para os "novos" requisitos, isto , os "antigos" que sofreram alteraes. Como tal, o planejamento uma parte importante da gesto de requisitos. Devem estar definidas desde o incio da gesto de requisitos polticas para: Identificao de requisitos, identificao unvoca em especial para facilitar a rastreabilidade; Processo de gesto de mudanas a utilizar, conjunto de atividades que permitem avaliar o custo e impacto das alteraes; Rastreabilidade, relaes entre os requisitos e design, na qual estas podem precisar manter associada a cada requisito informao como a parte interessada que a props, dependncias de outros requisitos e associao a mdulos especficos do design do sistema; e Ferramentas a utilizar, para sistemas grandes, a quantidade de informao a processar pode ser elevada, sendo o uso de ferramentas CASE. Para possibilitar a manuteno e consistncia entre as vrias alteraes solicitadas e para estas serem feitas de um modo controlado, importante que o processo de gesto de mudanas esteja definido de um modo formal, sendo que dever incluir as seguintes trs fases: Anlise do problema e especificao da alterao a fazer, identificao do problema existente nos requisitos originais e proposta de alterao a fazer aos requisitos do sistema; Anlise da alterao e seu impacto, atravs das polticas de rastreabilidade definidas previamente, avaliao do impacto da alterao no sistema; e Implementao da alterao, alterao no documento de requisitos e, conforme seja necessrio, no design e implementao. importante seguir este processo conforme foi enunciado j que cair na tentao de implementar a alterao diretamente e s depois, retrospectivamente, atualizar os requisitos pode levar a dessincronizao entre requisitos e implementao. Segue abaixo um exemplo de especificao bsica de requisitos funcionais de um sistema. Unidade 01 - Gerenciamento de usurio 1. Cadastro, edio e remoo de usurio 2. Login/logout dos usurios 3. Controle de permisso Unidade 02 - Gerenciamento de cliente 1. Cadastro, edio e remoo de consumidor/fornecedor Unidade 03 - Controle de Almoxarifado 1. Cadastro, edio e remoo de matria-prima 2. Adio e subtrao da matria-prima no almoxarifado Unidade 04 - Controle de Estoque 1. Cadastro, edio e remoo de produto 2. Adio e subtrao do produto no estoque Unidade 05 - Produo 1. Converso de matria-prima em produto Unidade 06 - Venda 1. Sada do produto do estoque 2. Contabilizar o pagamento 3. Atualizar o histrico de vendas Unidade 07 - Relatrio 1. Relatrio de clientes, almoxarifado, estoque, pedido, pagamento 2. Utilizar filtro na gerao de relatrios Unidade 08 - Nota fiscal eletrnica 1. Gerao de nota fiscal 2. Impresso de nota fiscal 3. Exportao de nota fiscal Unidade 09 - Boleto bancrio 1. Gerao de boleto bancrio 2. Impresso de boleto bancrio 3. Exportao de boleto bancrio Outro exemplo de especificao de requisitos de um sistema, mais detalhado: Controle de Acesso e Cadastro Bsico - Esta seo agrupa os requisitos funcionais associados ao controle de acesso e cadastros bsicos do sistema. RF001 Cadastrar/Alterar Usurio Mdulo: M01.01

RF001 Cadastrar/Alterar Usurio Mdulo: M01.01 O administrador do sistema ser o prprio Cuidador, que poder cadastrar outros cuidadores para utilizar o sistema. Sero cadastrados o nome, endereo residencial, telefone/email de contato, documentos de identificao, profisso com n de registro, login e senha inicial. Para alterao, o sistema permitir alterar todos os dados cadastrais do usurio, com exceo do nome de login - Prioridade: Essencial RF002 Acessar sistema Mdulo: M01, M02, M03 Para acessar o sistema, deve-se informar o login e a senha corretos. O login e a senha sero validados para permitir o acesso ao sistema. No 1 acesso do usurio, o sistema dever solicitar que seja trocada a senha inicial. - Prioridade: Essencial RF003 Sair do sistema Mdulo: M01, M02, M03 Ser disponibilizada opo para sair do sistema, encerrando a sesso do usurio conectado. - Prioridade: Essencial RF004 Cadastrar/Alterar Paciente Mdulo: M01.02 O sistema permitir cadastrar ou alterar os dados pessoais, plano de saude, familiares, histrico mdico e situao no sistema (ativo ou inativo) do paciente. - Prioridade: Essencial RF005 Cadastrar/Alterar Profissionais Mdulo: M01.03 O sistema permitir cadastrar ou alterar os profissionais que estaro diretamente ligados ao tratamento/acompanhamento do paciente. O sistema dever registrar a data e usurio que realizou o cadastro ou alterao. - Prioridade: Essencial RF006 Cadastrar/Alterar Servios e Estabelecimentos Mdulo: M01.04 O sistema permitir cadastrar ou alterar os servios ou estabelecimentos ligados ao tratamento/acompanhamento do paciente, como farmcias e hospitais. O sistema dever registrar a data e usurio que realizou o cadastro ou alterao. - Prioridade: Essencial RF007 Cadastrar Anamnese do Paciente Mdulo: M01.05 O sistema permitir cadastrar a Anamnese do paciente, contendo as informaes de histria pessoal, histria de doenas, histria patolgica pregressa, histria fisiolgica e histria psico-social. O sistema dever registrar a data e usurio que realizou o cadastro. - Prioridade: Essencial RF008 Complementar Anamnese do Paciente Mdulo: M01.05 O sistema permitir complementar as informaes da Anamnese do paciente. O sistema dever registrar a data e usurio que realizou o complemento. - Prioridade: Essencial Acompanhamento do Paciente - Esta seo agrupa os requisitos funcionais associados ao registro de informaes de acompanhamento do paciente. RF009 Cadastrar/Alterar Lanamentos Dirios Mdulo: M02.01 O sistema permitir incluir ou alterar o registro de informaes dirias sobre o acompanhamento do paciente, sendo estas informaes do tipo TEXTO. O sistema tambm dever registrar a data e usurio que realizou o cadastro ou alterao. - Prioridade: Essencial RF010 Cadastrar/Alterar Lembretes e Avisos Mdulo: M02.02 O sistema permitir incluir ou alterar lembretes com as informaes de Tipo do Lembrete, Data e Hora do Lembrete, Descrio do Lembrete e Freqncia de Repetio do Lembrete, onde assim que o horrio programado para lembrete for atingido, o sistema emitir uma mensagem com a descrio do lembrete. - Prioridade: Essencial RF011 Visualizar Proximos Lembretes Mdulo: M02.02 O sistema permitir visualiar os prximos lembretes ativos ordenados pela data/hora de aviso. - Prioridade: Importante RF012 Alterar Tipo de Alerta Mdulo: M02.02 Ser possvel alterar o tipo de alerta dos lembretes, como alerta sonoro ou textual.

Ser possvel alterar o tipo de alerta dos lembretes, como alerta sonoro ou textual. - Prioridade: Importante RF013 Cadastrar/Alterar Alimentao Mdulo: M02.03 O sistema permitir cadastrar ou alterar a alimentao especfica por paciente, informando o cardpio semanal e o valor nutricional dos alimentos. - Prioridade: Essencial RF014 Cadastrar/Alterar Vacinao Mdulo: M02.04 O sistema permitir cadastrar ou alterar vacinao especfica por paciente, informando o tipo de vacinao, a data em que foi aplicada e seu vencimento. - Prioridade: Essencial RF015 Visualizar Proximas Vacinaes Mdulo: M02.04 O sistema permitir visualiar as prximas vacinaes do paciente, baseando-se na data de vencimento registrado no mdulo de cadastro da vacinao. - Prioridade: Importante RF016 Cadastrar/Alterar Medicao Mdulo: M02.04 O sistema permitir cadastrar ou alterar medicao especfica por paciente, informando a prescrio de cada medicamento e sua posologia. - Prioridade: Essencial Consulta de Informaes - Esta seo agrupa os requisitos funcionais associados consulta de informaes registrada no sistema. RF017 Consultar/Imprimir Anamnese Mdulo: M03.01 O usurio poder consultar na tela ou atravs da opo de impresso, todas as informaes da Anamnese do paciente. No caso de impresso, automaticamente sair descrito no rodap do relatrio Documento informativo. No possui valor mdico. - Prioridade: Essencial RF018 Consultar/Imprimir Relatrios - Mdulo: M03.02 O usurio poder consultar na tela ou atravs da opo de impresso, todas as informaes registradas no mdulo de Acompanhamento (M02), como os Lanamentos Dirios, Relao de Lembretes Ativos, Relao da Alimentao Atual e Relao da Medicao Atual. No caso de impresso, automaticamente sair descrito no rodap do relatrio Documento informativo. No possui valor mdico. - Prioridade: Essencial Embora no exista um modelo consagrado para especificao de requisitos o mais usado baseado nos padres propostos pelo RUP. O importante garantir a qualidade do processo e a Norma ISO/IEC 9126 define seis caractersticas de qualidade de software que devem ser avaliadas: Funcionalidade (finalidade do produto) - Conjuntos de recursos; Habilidades; e Segurana;

 Usabilidade (esforo para utilizar, aprender o produto) - Fatores humanos; Esttica; Consistncia na interface do usurio; Ajuda on-line e contextual; Assistentes e agentes; Documentao do usurio; e Materiais de treinamento;

Confiabilidade (freqncia de falhas, recuperabilidade) - Freqncia e gravidade de falha; Possibilidade de recuperao; Possibilidade de previso; Exatido; e Tempo mdio entre falhas;

Eficincia (caracterstica relacionada ao desempenho) Velocidade; Eficincia; Disponibilidade; Exatido; Taxa de transferncia; Tempo de resposta; Tempo de recuperao; e Uso de recurso;

Suportabilidade (esforo necessrio para modificar) - Possibilidade de teste; Extensibilidade; Adaptabilidade; Compatibilidade; Possibilidade de configurao; Possibilidade de servio; Possibilidade de instalao;

de configurao; Possibilidade de servio; Possibilidade de instalao; Possibilidade de localizao (internacionalizao); e

Portabilidade (capacidade de transferir o produto para outros ambientes).

Finalizando essa aula, no desenvolva ADHoc ;)

Vimos que sem uma boa gerencia de requisitos, a possibilidade de fracasso na construo de um produto de software bem maior. Mas, para reforar essa engenharia, surge o Paradigma Orientado a Objetos (POO), no qual os requisitos podem ser modelados e validados atravs de casos de uso que incluem o diagrama de casos de uso e a especificao do caso de uso. Um caso de uso representa uma funcionalidade completa, conforme percebida pelo ator e definido como um conjunto de seqncias de aes que um sistema executa e que produzem um resultado observvel por um particular ator. Os casos de uso so uma das tcnicas usadas para descrever claramente todos os requisitos de um dado sistema, esta tcnica foi proposta por Ivar Jacobson em sua metodologia de desenvolvimento de sistemas orientados a objetos, visando identificar os requisitos de um sistema. Terceira atividade baseado no documento de especificao de requisitos de software do RUP, crie uma necessidade imaginria e faa a especificao e em seguida armazene na ATV3 no formato PDF com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf. Principais Referncias Antnio Soares. Introduo, Identificao e Anlise em Engenharia de Requisitos, 2005. James Rumbaugh; Ivar Jacobson; Grady Booch. UML: Guia do Usurio - 2006. Ian Sommerville. Engenharia de Software - 8 Edio, 2007. Links Tcnicas para Coleta de Dados Tcnicas de Levantamento de Requisitos por Pedro Carvalho Tcnicas de Levantamento de Requisitos Mtodo Volere por Pedro Carvalho

Tcnicas de Levantamento de Requisitos Mtodo Volere por Pedro Carvalho Tcnicas de Levantamento de Requisitos No Funcionais Alguns exemplos de artefatos
Plano de Negcio Modelo de Negcio Glossrio de Negcio Viso Plano de Requisitos Requisitos de Softw are Proposta Comercial Termo de Abertura do Projeto

AULA 04 - Mtricas
Temos os requisitos e agora? No se consegue controlar o que no se consegue medir Tom Demarco Uma dvida que me perseguiu por muito tempo foi, como determinar o prazo e custo do desenvolvimento de um produto que ainda no temos todos os requisitos levantados e sim a previso do que dever ser feito. A resposta foi chegando aos poucos, com as tentativas frustadas de estimar prazos e custos de algo que na sua totalidade era desconhecido. Assim, fui percebendo que no h como determinar o tamanho de um software, por mais que se possua experincia, e por mais que as conversas iniciais com o cliente sejam exclarecedoras. Sem fazer o levantamento de requisitos, o que poderemos ofertar aos contratantes apenas uma estimativa e est na tcnica do "chutometro". Pode-se at acertar, se o fator experincia, expertice do negcio e sorte, estiverem do seu lado. Mas, por mais veterano que voc e sua equipe possa ser, o domnio do negcio a ser desenvolvido no uma obrigatoriedade, e infelizmente o fator sorte uma incgnita. Ento, o que fazer? Bom, quando disse que a resposta chegou, ela veio com o nome mtrica. Resumindo, no h como estimar com boa aproximao, ou determinar o tamanho de um software, se no fizermos o uso de uma mtrica. E para coraborar com o que digo, segue a citao de Peter Drucker "A melhor estrutura no garantir os resultados nem o rendimento. Mas a estrutura errada a garantia do fracasso." Podemos entender que, caso no use uma mtrica apropriada ou no use nenhuma mtrica, a possibilidade de mensurar errado muito alta, caso use a mtrica certa, a possibilidade de acerto j passa a existir e num percentual aceitvel. ;) Agora o que uma mtrica? Mtrica pode ser: na literatura um conceito relacionado ao ritmo de um poema; na matemtica um conceito ligado a distncia; na msica um conceito sobre a diviso de uma linha musical em compassos; e na Engenharia de Software (ESW) um conceito relacionado gerncia de projetos. Bom, se estamos falando em engenharia, isto , construo de algo, no podemos deixar de falar em medio, que algo intimamente ligado a criar ou construir algo. E um software tambm precisa ser medido. Porm, essa uma tarefa no muito fcil, j que estamos falando da construo de algo abstrato, que um software, e assim sendo, possuindo um grau de subjetividade alto. E tudo que subjetivo, est a merc de interpretao as mais diversas, j que nesse caso, as referncias, a experincia, entre outros fatores, influenciam a interpretao. Dessa forma, no existe ainda na ESW uma medio padro aceito amplamente pela comunidade e que fornea resultados sem subjetividade. Isso tornar o processo de medir, muito rduo e muitas vezes, gerador de conflitos do tipo, o que medir, o que avaliar, e se os resultados so aceitveis.

Mas, quando fiz o curso de Anlise de Pontos de Funo (APF) o professor Guilherme Simes autor do livro citado na referncia, que certificado em AFP pelo IFPUG e utilizada essa mtrica h muitos anos, nos disse que, ela no a melhor mtrica que existe, muito longe disso, mas em relao ao que existe hoje no mercado, ainda a melhor. Assim, temos que ter conscincia que medir o tamanho de um software necessrio, mas que qualquer mtrica escolhida, ter suas limitaes. Mas, sem uma mtrica o processo de gerenciar a construo de um produto de

escolhida, ter suas limitaes. Mas, sem uma mtrica o processo de gerenciar a construo de um produto de software, planejando seu esforo, seu custo, seus recursos, suas atividades seu prazo, etc, torna-se uma caixa preta cheia de surpresas desagradveis. As mtricas na ESW so divididas em duas categorias, as quais so: Direta. Focada na medio do custo e do esforo de construo, isto , tanto o desenvolvimento com a manuteno, seja ela evolutiva ou corretiva. Analisando a quantidade de Linhas de Cdigo Fonte (SLOC) produzidas e o total de defeitos encontrados. Exemplos: custo, esforo, linhas de cdigo, velocidade de execuo, memria, nmero de erros, e complexidade ciclomtica, isto , a quantidade de caminhos de execuo independentes a partir dum cdigo fonte; e Indireta. Focada na qualidade e na funcionalidade do produto de software, em relao a aplicabilidade do software. Exemplos: funcionalidade, qualidade, complexidade, eficincia, confiabilidade, e manutenibilidade. Essas ainda podem ser divididas em outras duas subcategorias, as quais so: Produtividade. Focada nas sadas do processo de engenharia de software; e Qualidade. Focada no atendimento aos requisitos definidos pelo usurio. Quais so as principais mtricas da Engenharia de Software? Pontos de Funo (APF) que mede o tamanho funcional do software. Saber mais. Pontos de Caso de Uso que mede o tamanho de um software a partir da utilizao do mesmo pelos usurios. Saber mais. COnstructive COst MOdel (COCOMO) que mede o tempo de desenvolvimento de um software. Saber mais. Qual mtrica usar? Como dito anteriormente a mtrica que mesmo no sendo a melhor, mas a que produz resultados menos conflitantes a APF e essa que vamos usar. Como surgiu a APF? A Anlise de Pontos de Funo (APF) ou Function Point Analysis (FPA), foi criada em 1979 na IBM, tornando-se um referncia mundial na dcada de 80. A APF um conjunto de tcnicas que objetivam medir as funcionalidades, sendo assim, uma unidade de medida para fins prticos, no importando a tecnologia utilizada na construodo software. Resumindo, uma mtrica capaz de mensurar o tamanho do software. O rgo responsvel pela manuteno e divulgao das diretrizes da APF o International Function Point Users Group (IFPUG), que publicou e mantm o Manual de Prticas de Contagem de Pontos de Funo Counting Practices Manual (CPM). Como se calcula pontos de funo? O objetivo da Anlise de Pontos de Funo (APF) obter o tamanho de um software em Pontos de Funo (PF) analisando as funcionalidades a serem desenvolvidas, isto , os requisitos funcionais. Porm importante salientar que essa funcionalidade sob o ponto de vista do usurio (PVU). Mas, o que quer dizer sob o ponto de vista do usurio? Significa que um Requisito Funcional (RF) tipo o que se segue RF001 deve ser analisado aos olhos do usurio e no do desenvolvedor. RF001 - [...] necessrio armazenar os dados do cliente como CPF; nome; endereos residencial, comercial e de contato; telefones residencial, comercial, contato, celular; e-mails; sexo; nascimento; filiao; emprego atual; tempo de trabalho; emprego anterior; e faixa salarial [...]. Se um desenvolvedor fizer a leitura desse requisito, obviamente ele saber que ter trabalho pela frente. Visto que, na sua viso tecnicista, j visualiza a modelagem do banco, que normalizar esse entrada em diversas tabelas, caso a persistncia dos dados seja em um banco de dados relacional, e que uma srie de classes de domnio, de controle, de persistncia e de apresentao, tero que ser criadas, caso do desenvolvimento for numa linguagem orientada a objetos. Alm da usabilidade, que exigir uma interface grfica (GUI) bem amigvel, j que o cadastro poder produzir vrias vises para um nico cadastrador. Resumindo, sob ponto de vista do desenvolvedor (PVD), isso vai dar um trabalho danado. Porm, para o PVU se trata

Resumindo, sob ponto de vista do desenvolvedor (PVD), isso vai dar um trabalho danado. Porm, para o PVU se trata de um cadastro nico. No qual sero cadastrados todos os dados acima levantados e simplesmente o utilizador ir clicar em um boto salvar e pronto. Para o PVU muito simples. Qual o trabalho que tem isso? :) Agora, por qu se deve analisar pelo PVU? A resposta : Para que a medio de um projeto de desenvolvimento de software e a manuteno deste no se preocupe com a tecnologia a ser utilizada na sua implementao e sim, apenas nas funcionalidades do sistema requisitadas pelo usurio. Explicando melhor, se voc for desenvolver o RF001 em Clipper, ou em Pascal, ou em Delphi, ou Visual Basic, ou Java, ou CSharp, etc, o grau de esforo para cada linguagem diferente, como tambm diferente com o uso do tipo de arquitetura de banco de dados, se banco relacional uma, se banco orientado a objetos outra, assim a medio sofreria uma grande variao devido ao fator tecnologia empregada. Ento, a mesma tem que ser isenta dessa preocupao, s focando nas necessidades do usurio. Quais so as aes para se contar pontos de funo?

Entendido o que uma mtrica e o que se prope a Anlise de Ponto de Funo, vamos aprender a contar PFs. A primeira ao, determinar qual o tipo de contagem de pontos de funo que dever ser realizada. Podem ser de trs tipos: Projeto de Desenvolvimento (PD); Aplicaes Instaladas (AI); e Projetos de Manuteno (PM). A segunda ao, realiza a identificao do escopo de contagem, com a determinao da fronteira da aplicao, isto , definir quais sero as funcionalidades que sero includas na contagem de PFs. Para isso a definio da fronteira da aplicao fundamental, pois estabelece as fronteiras entre aplicao, usurio e outras aplicaes.

A terceira ao determinar a contagem de Pontos de Funo No Ajustados (PFNA), isto , verificar requisitos funcionais levantados, e classific-los em dados e transaes. A quarta ao, a contagem dos dados. Para contar os dados se leva em considerao os dados internos os chamados Arquivos Lgicos Internos (ALI) e os dados externos os denominados Arquivos de Interface Externa (AIE) da aplicao. Ambos representam um grupo de dados logicamente relacionados que foram identificados pelo usurio. A diferena que os ALIs so mantidos dentro da fronteira e os AIEs so os mantidos fora da fronteira da aplicao. Simplificando, os ALIs so persistidos pelas operaes da aplicao, enquanto os AIEs so referenciados pela aplicao, mas no persistidos por ela. Exemplo, no RF001 teremos que armazenar no banco de dados da aplicao os dados do cliente, e neste caso teremos 1ALI, mas existe um requisito RF002 relacionado ao RF001 que diz: RF002 - todos os endereos devem ser validados por CEP que deve ser consultado na base de dados dos correios. Assim, para o referido cadastro do usurio, teremos 1AIE j que a persistncia dos dados de CEPs feita pelos correios que outro sistema que se relaciona com o desenvolvido e est fora da fronteira da aplicao. A quinta ao, consiste na contagem das transaes. Para contar as transaes se leva em considerao as funcionalidades de processamento de dados do sistema fornecidas para o usurio. Esses so classificadas em Entradas Externas (EE), as Sadas Externas (SE) e as Consultas Externas (CE). As EEs so os processos responsveis em manter os ALIs. As SEs so os processos responsveis em exibir as informaes recuperadas atravs de um processamento lgico, com a realizao de clculos. As CEs so os processos responsveis em exibir as informaes recuperadas atravs de um processamento lgico, sem a realizao de clculos. A seguir seguem as tabelas definidas pelo IFPUG para determinar a complexidade funcional.

A seguir seguem as tabelas definidas pelo IFPUG para determinar a complexidade funcional. A tabela ao lado define a complexidade das funes de dados, isto , os ALIs e os AIEs.

A tabela ao lado define a complexidade das entrada e sadas, isto , EEs.

A tabela ao lado define a complexidade das funes de dados, isto , os ALIs e os AIEs.

A tabela ao lado a contribuio do IFPUG para determinar os pesos para a quantidade de ocorrncias de dados e transaes encontrados na anlise dos requisitos funcionais.

A sexta ao, serve para verificar as complexidades. Encontrados os ALIs, os AIEs, as EEs, as SEs e as CEs, deve-se verificar as suas complexidades funcionais e classific-las em baixa, mdia ou alta. Essas complexidades so definidas com base em dois conceitos, os Tipos de Registros (TR) e os Tipos de Dados (TD). Os TRs correspondem ao conjunto de dados dentro de um ALI/AIE, que foram reconhecidos pelo usurio, exemplo, imagine o cadastramento de uma venda, teramos no mnimo trs tabelas de dados envolvidas no processo, a de vendas, itens-da-venda e a de produtos, mas todas as trs seriam consideradas apenas 1RL. Os TDs so os campos reconhecidos pelo usurio como nicos e no repetidos, exemplo, o cadastro de cliente do RF001, temos o cpf, o nome, os fones comercial, residencial e celular, neste caso, temos 3ID's, j que os fones devem ser contados como 1ID. Contando-se os RLs e os IDs de um ALI/AIE, pode-se chegar sua complexidade. Exemplo de Planilha de Contagem (PC)

Acima temos um exemplo de uma planilha de contagem. Para obter essa planilha e as tabelas de complexidade clique aqui. A stima ao, realizar a contagem dos pontos de funo, considerando-se o tipo de contagem definida na primeira ao. O processo de contagem relativamente simples, consiste em separar os requisitos funcionais, analisar para cada RF os elementos bsicos necessrios, depois identificar nesses quantos ALIs, AIEs, EEs, SEs e CEs existem, para depois verificar em cada um deles quantos TRs e TDs so encoontrados. Pronto, agora s preencher a Planilha de Contagem (PC), tomando como base as Tabelas de Complexidade acima exibidas. Por exemplo, supondo que para o requisito RF001 tenhamos encontrados dos elementos bsico incluir cliente, alterar cliente, excluir cliente, consultar cliente e imprimir cliente. Fazendo a anlise de PF teramos, 1ALI, 1AIE, 3EE, 1SE e 1CE. Ok, agora contar quantos TRs e TDs sero encontrados para cada um dos dados e transaes encontrados. Supondo novamente que tenhamos para o primeiro EE, 2TR e 25TD, para o segundo EE, 1TR e 15TD, e para o terceiro EE, 1TR e 32TD. Com esse levantamento, podemos fazer a verificao com as tabelas e com o cruzamento dos dados obtemos a complexidade, se baixa, mdia ou alta. A oitava ao, obter o total de pontos de funo no ajustados (PFNA), que obtido pelo somatrio dos pontos. Esse consiste de aps realizar o preenchimento das colunas "Processo Elementar", "Tipo", "TD", "TR" e "Complexidade" da Planilha de Contagem, basta fazer o batimento com a Tabela de Contribuio e lanar os pesos na coluna "PF". Pronto, s fazer o somatrio dos PFs e se obter o PFNA, com outras palavras, temos o tamanho do software, que diramos para exemplificar 2500PFs. Com esse tamanho determinado j se pode obter o prazo e o custo para o esforo de construo, criando-se uma relao entre a complexidade e o tempo para resolv-la, e o tamanho multiplicando por um valor equivalente a 1PF. Supondo que 1PF equivale a R$80,00 ento 2500PFs aplicando a regra de trs equivale a R$200.000,00. Temos a o custo do desenvolvimento, sem levar em considerao os componentes indiretos da mtrica, isto , as 14 caractersticas j citadas. A nona ao, deve determinar o valor do fator de ajuste, isto , avaliar 14 caractersticas gerais de sistemas, que avaliam a funcionalidade geral da aplicao que est sendo contada e seus Graus de Influncia (GI). O GI determinada com base na seguinte escala: 0=Nenhuma influncia; 1=Influncia mnima; 2=Influncia moderada; 3=Influncia mdia; 4=Influncia significante; e 5=Influncia forte. A dcima ao, aplicar o fator de ajuste de influncia nos PFNA que fica na ordem de +/- 35%, aplicando-se as 14 caractersticas gerais dos sistemas, a saber: 1=Comunicao de Dados; 2=Processamento de Dados Distribudo; 3=Desempenho; 4=Utilizao do Equipamento (Restries de Recursos Computacionais); 5=Volume de Transaes; 6=Entrada de Dados On-line; 7=Eficincia do Usurio Final (Usabilidade); 8=Atualizao On-line; 9=Processamento Complexo; 10=Reusabilidade; 11=Facilidade de Implantao; 12=Facilidade Operacional (Inicializao, Cpia, Recuperao, etc); 13=Mltiplos Locais e Organizaes do Usurio; e 14=Facilidade de Mudanas (Manutenibilidade). Para cada uma dessas 14 caractersticas deve-se atribuir um dos GIs para determinar o nvel de influncia, que indicar o quanto determinada a caracterstica tem influncia no sistema. Os 14 graus de influncia (GIs) informados so somados, resultando no Nvel de Influncia Total (NIT). A dcima primeira ao, consiste em determinar o Valor do Fator de Ajuste (VFA) pela frmula VFA = (NIT * 0,01) + 0,65. A dcima segunda ao, o clculo dos Pontos de Funo Ajustados (PFA). Esse clculo depende do tipo de projeto, se desenvolvimento, se manuteno ou se aplicaes instaladas. Se for um projeto de desenvolvimento de sistemas ento a frmula Projeto_Desenvolvimento = Ponto_Funo_No_Ajustado * Valor_Fator_Ajuste. Se for para o dimensionamento de sistemas j implantados, isto , em produo, temos, Aplicao_Implantada = Projeto_Desenvolvimento - (Pontos_Funo_No_Ajustados x Fator_Ajuste), e para dimensionamento de sistemas j

Projeto_Desenvolvimento - (Pontos_Funo_No_Ajustados x Fator_Ajuste), e para dimensionamento de sistemas j implantados. mas em manuteno, temos, Projeto_Manuteno = (Pontos_Funo_No_Ajustado + Ponto_Funo_Includo + Ponto_Funo_Alterado_Atual - Ponto_Funo_Alterado_Anterior Ponto_Funo_Excludo) x Fator_Ajuste_Atual. Com isso, se tem o tamanho do software e com esse tamanho (x PF's), pode-se determinar um valor a ser pago por cada ponto de funo, e a partir dele determinar o valor total do software, alm de determinar formas de pagamentos, relacionadas as entregas realizadas. Exemplo: se o tamanho do software de 2.500PFs e se paga R$80,00 por cada PF o valor total a ser pago de R$200.000,00. Mas, se no planejamento de entregas, ficou determinado que a contratada deveria entregar 50PFs no ms e s entregou 25PFs, o que ser pago pela contratante a contratada, o trabalho realizado, assim sendo, ela receber R$2.000,00 pelo trabalho feito, ficando os 25PFs desse ms, para o prximo ms acrescidos dos outros 50PFs que j se tinham planejado. Controle efetivo do que se tem a produzir e do que produzido. Clicando aqui pode-se obter uma Tabela de Referncia de PF para cada linguagem de programao. Segue um resumo de todas as aes pode ser visto a figura a seguir.

Quarta atividade crie um requisito fictcio e tente contar quantos pontos de funo voc consegue encontrar. Armazene na ATV4 com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf. Principal Referncia Carlos Vazques, Guilherme Simes e Renato Albert. Anlise de Pontos de Funo: Medio, Estimativas e Gerenciamento de Projetos de Software. Editora Afiliada, 10a.Edio, 2010. Saber mais. Links International Function Point Users Group (IFPUG) Brazilian Function Point Users Group (BFPUG) Fatto Consultoria e Sistemas - empresa especializada em mtricas Perguntas e Respostas sobre APF BFPUG Template da Planilha de Contagem de Pontos de Funo Ferramentas APFPlus Metric Studio for FPA Bibliografias Peter Ferdinand Drucker, austraco nascido 1909 e que falesceu rescentemente em 2005, foi um filsofo e economista, que por suas contribuies a comunidade, passou a ser considerado o pai da administrao moderna, se tornando um dos pensadores mais citados pela teoria da globalizao em economia em geral. Saber mais.

dos pensadores mais citados pela teoria da globalizao em economia em geral. Saber mais. Tom DeMarco, nascido em 1940 na Pensilvnia, autor, professor e palestrante em engenharia de software e reconhecido como um dos criadores da Anlise Estruturada nos anos 1980. Bacharel em Engenharia Eltrica pela Universidade de Cornell University, Mestre pela Columbia University e Doutor pela University of Paris at the Sorbonne. Saber mais. Recurso Complementar Segue uma vdeo aula para exemplificar como contar pontos de funo:
Video Aula

http://youtube.com/watch?v=N3AO3JKaLa4

AULA 05 - Anlise de Sistemas

Anlise e Modelagem Como visto anteriormente, na aula sobre RUP, esse processo possui 4 marcos, os quais so: Marco dos objetivos do ciclo de vida; Marco da arquitetura do ciclo de vida; Marco da capacidade operacional inicial; e Marco do lanamento do produtoo. Agora que passamos pelo primeiro marco, temos que comear a modelar os requisitos especificados. O cliente necessita entender o que os projetistas esto construindo e precisam ter condies de inferir os seus conhecimentos nos projetos para atender plenamente suas necessidades. Para isso necessrio estabelecer um canal formal de interao onde a linguagem natural do cliente transformada em linguagem tcnica para a equipe de desenvolvimento. Com esse objetivo a UML se prope a ser uma linguagem padro aceita e compreendida por todos os stakeholders. A modelagem utilizando a Linguagem de Modelagem Unificada, mais conhecida atravs da sigla em ingls UML que significa Unified Modeling Language focada no paradigma Orientado a Objetos (OO) cujos conceitos so classe, objeto, herana, polimorfismo, encapsulamento de atributos e mtodos, alta coeso e baixo acoplamento. usado para a anlise no focando na codificao do software ou hardware e sim no entendimento do problema (anlise) e na sua soluo (projeto). A UML representa smbolos, esses usados em diagramas que assim representam uma linguagem simblica com regras claras e precisas para utilizao desses smbolos nos diversos diagramas. O objetivo dos diagramas apresentar mltiplas vises do sistema chamado de modelo. Assim, um modelo UML um conjunto de diagramas que servem para compreender e desenvolver um projeto de software, descrevendo o que o software deve fazer. A seguir segue uma breve descrio dos diagramas da UML.

Como surgiu a UML? Durante a dcada de 80, vrias linguagens de programao se popularizaram, entre elas uma que se destacou foi a chamada de Smalltalk, mas outras linguagens tambm participaram deste movimento, tais como, Objective C, C++ e Eiffel, todas projetadas para o paradigma orientado a objetos. Seguindo esta onda, os mtodos orientados a objetos comearam a ser publicados. Como exemplo temos em 1988 o de Shlaer, em 1990 o de Wirfs-Brock, em 1991 o de Coad e Yourdon, ainda em 1991 de Booch, e tambm em 1991 o de Rumbaugh. A primeira tentativa de sucesso de se criar uma linguagem unificada aconteceu quando Rumbaugh se juntou a Booch na Rational Software Corporation em 1994. Eles comearam a combinar conceitos de OMT com os mtodos de Booch, produzindo um mtodo unificado. Neste mesmo momento Jacobson tambm se juntou a Rational e comeou a trabalhar com Booch e Rumbaugh. O trabalho conjunto resultou no que foi chamado de Unified Modeling Language (UML). Este foi um momento nico, quando os autores dos trs principais mtodos trabalharam juntos para unificar suas propostas. Em 1996, a Object Management Group (OMG) fez uma chamada por propostas com o objetivo de criar um padro para modelagem orientada a objetos. Ao autores da UML comearam a trabalhar com metodologistas e desenvolvedores de outras empresas para produzir uma proposta atrativa para os membros da OMG, assim como para as empresas de ferramentas, metodologistas e desenvolvedores em geral. No final de 1997, se tornou um padro da OMG e at hoje vem sendo mantida e evoluda, sendo hoje bem aceita por toda a comunidade de desenvolvimento de software. O que a UML? A Unified Modeling Language (UML) a sucessora de uma onda de mtodos para anlise e projeto orientados a objetos que surgiram no fim da dcada de 80. Ela unificou os mtodos proposto por Booch, Rumbaugh e Jacobson. Atualmente a UML um padro mantido pela OMG, o que d a ela um status de linguagem padro para modelagem de sistemas, isto , uma linguagem padro para visualizar, especificar, construir e documentar artefatos de um sistema de software e combina diversos aspectos como: Modelagem Modelagem Modelagem Modelagem de Dados de Negcios de Objetos de Componentes

importante enfatizar que UML uma linguagem de modelagem, ou seja, uma forma de especificar um sistema de maneira visual. Ela a linguagem padro de modelagem adotada pelo Rational Unified Process (RUP) e seu grande sucesso se deu em conjunto com a popularizao do RUP. Por isso, muito comum que as pessoas associem UML ao RUP. importante distinguir muito bem, visto que as duas representam conceitos complementamente diferentes. O RUP um processo, ou seja, um conjunto de atividades, com seus respectivos artefatos e ppeis, para se desenvolver produtos de software e a UML uma linguagem para se modelar o comportamento e estrutura de um sistema. Quinta atividade revisar os seguinte conceitos de POO: pacotes; classe concreta; classe abstrata; interface; superclasse; classe pai e filha; atributo; mtodo; mtodo esttico; construtor; destrutor; objeto; herana simples e mltipla; encapsulamento; polimorfismo; sobrecarga e sobreescrita; modificadores (pblico, privado, protegido e pacote); mensagem; associao; agregao; composio; abstrao; coeso, acoplamento; e reuso. Armazena na ATV5 com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf. Principais Referncias

Principais Referncias James Rumbaugh; Ivar Jacobson; Grady Booch. UML: Guia do Usurio - 2006. Ernani Medeiros. Desenvolvendo Software com UML 2.0: definitivo - 4 Edio, 2008. Ana Cristina Melo. Desenvolvendo Aplicaes com UML 2.2: do conceitual implementao - 3 Edio, 2011. Links Object Management Group (OMG) Unified Modeling Language (UML) Rational Unified Process (RUP) Object-Oriented Programming (OOP) Design Patterns Languages for Object-Oriented Programs (DP) A Theory of Object-Oriented Desig IBM Rational Unified Proces Biografias James Rumbaugh, nasceu em 1947 e Bacharel em Fsica pelo MIT, possui mestrado em Astronomia pela Caltech, e Ph.D. em Cincia da Computao tambm pelo MIT. Trabalhou na Digital Equipment Corporation (DEC), como cientista. Foi um dos lderes na criao da OMT e em 1994 se juntou a Rational Software, e junto com Ivar Jacobson e Booch de Grady desenvolveram a Unified Modeling Language (UML). Mais tarde, eles fundiram as suas metodologias de desenvolvimento de software, OMT, OOSE e Booch em um nico processo batizado de Rational Unified Process (RUP). Saber mais. Ivar Jacobson, um sueco nascido em 1939, se graduou no Instituto de Tecnologia de Chalmers, onde fez seu mestrado em Engenharia Eltrica e possuindo doutorado pela Royal Institute of Technology de Estocolmo. Saber mais. Grady Booch, nasceu em 1955 nos Estatos Unidos, engenheiro de software e cientista-chefe da IBM Research. Obteve seu grau de bacharel pela United States Air Force Academy e ttulo de mestre em engenharia eltrica pela Universidade da Califrnia em Santa Barbara. Saber mais. Ferramentas http://case-tools.org/uml.html http://astah.change-vision.com/en/index.html

AULA 06 - Modelagem de Casos de Uso

Diagrama de Casos de Uso

O diagrama de caso de uso segundo Ivan Jacobson, um caso de uso um documento narrativo que descreve a seqncia de eventos de um ator que usa um sistema para completar um processo". Um caso de uso uma tcnica de modelagem que descreve o que o novo sistema deve fazer e se baseia em um processo de licitao de requisitos entre os stakeholdres na conduo de uma especificao na qual todos interagem. Um caso de uso descreve quais comportamentos o sistema dever responder para cada um dos usurios do mesmo, servindo de formalizao das aes que preciso ser desenvolvidas. Retratando uma lista de eventos entre os usurios e o sistema em uma viso abstrata, onde essa lista de eventos relatados abstratamente descreve as interaes desde o incio da atividade at o fim da mesma. Casos de uso tm que ser compreensveis pelos usurios por que s eles sabem o que o sistema precisa fazer. Os casos de uso permitem verificar se o desenvolvedor e o usurio concordam sobre o que o sistema deve fazer. Isso um problema importante no desenvolvimento de software. No mesmo tempo, casos de uso podem servir de "contratos'' entre os usurios e os desenvolvedores. Sendo assim os casos de uso devem: Descrever os requisitos funcionais do sistema;

Fornecer uma descrio clara do que se deve fazer; e Definir os comportamentos das classes. importante salientar que casos de uso no so requisitos. E sim uma viso abstrata desses os quais so compostos pelos seguintes componentes: Ator, que um papel que solicita eventos ao sistema e recebe feedbacks, onde cada ator pode participar de vrios casos de uso; e Casos de uso so documentos narrativos que descrevem a seqncia dos eventos feitos por um ator no uso do sistema. Os elementos que descrevem esses papis so exibidos abaixo. Vale salientar que o nome dos casos de uso deve ser composto por frases curtas, preferencialmente verbo + substantivo. Exemplo: matricular aluno.

Para especificar um caso de uso pode-se usar a estrutura que se segue, porm no existe uma estrutura rgida: Cdigo do caso de uso; Nome do caso de uso; Descrio do caso de uso (um pargrafo); Lista dos nomes dos atores com descrio curta; Prioridade, caso de uso muito importante no projeto ou acessrio; Pr-condies; Ps-condies; Fluxo de eventos principal; Fluxos de eventos alternativos; Fluxo de eventos de excees; Cenrios; e Dicionrio de Dados. Clique aqui para obter Template RUP para Especificao de Casos de Uso Clique aqui para obter Template Mais Detalhado para Especificao de Casos de Uso Para identificar os atores que vo participar do modelo uma das tcnicas fazer as seguintes perguntas: Quem Quem Quem Quem usa o sistema? inicia o sistema? fornece os dados? usa as informaes?

Na descrio dos atores geralmente se faz o uso de: Nome do caso de uso; Tipo de uso se frequente, ocasional, etc...; Descrio de seu papel no sistema. Para identificar os casos de uso, normalmente a tcnica usada : Verificar as interaes entre os atores e o sistema; e Verificar as aes do ator e do sistema. importante salientar que os atores sempre iniciam a ao. Para entendimento imagine o requisito em que um aluno necessita fazer um curso, onde existe a necessidade de um sistema de matrculas. Ento: Quais so os atores? Quem usa o sistema? Como podemos identificar o caso de uso? Podemos chamar este caso de uso de: Matricular Aluno (verto+substantivo). Para fazer uma descrio textual do caso de uso, que possui dois atores Aluno e Administrao. Sua especificao poderia ser: Caso de uso:

Caso de uso: Matricular Aluno. Atores: Aluno, Administrador. Descrio: Este caso de uso comea quando um aluno chega administrao que faz a matrcula do aluno no curso. Fluxo: P1-O sistema registra a matrcula; P2-Recebe o pagamento; P3-Emite uma nota fiscal; e P4-O aluno matriculado. Na UML temos o diagrama de caso de uso que pode ser representado para o caso acima da seguinte forma:

Importante: o caso de uso deve comear com um verbo, enfatizando o processo. Exemplo: Matricular Aluno ou Cadastrar Curso. Deve-se identificar o ator que inicia o evento, comeando a descrio da seqncia de um caso de uso usando o esquema - este caso de uso comea quando um aluno faz uma matricula em um curso. Verifique que um ator um elemento externo ao sistema. Um ator um papel que interage com o sistema, mas no faz parte dele. O primeiro passo identificar os casos de uso bsicos, o prximo passo identificar o relacionamento entre os casos de uso atravs das generalizaes, incluses e extenses. As incluses so um caso de uso que inclui o comportamento de outro. A finalidade bsica da incluso realizar uma decomposio funcional e reduzir a complexidade de um caso de uso.

As extenses definem pontos que adicionam um comportamento opcional, assim o caso de uso base pode ser executado mesmo que a extenso no o seja.

De princpio as generalizaes so mais indicadas para as caractersticas dos atores, porm podem ser usadas com cautela para indicar especializaes de comportamentos.

Sexta atividade elaborar um requisito de software e depois criar na ferramenta Astah o diagrama de caso de uso para esse RF, finalizando com a especificao de caso de uso, baseado no template RUP fornecido. Armazene na ATV6 com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf. Links Mais sobre relacionamentos de Incluso e Extenso Guia Bsico sobre UML Manuais de Referncia OMG-UML Aulas de UML Exemplo de Modelagem UML Exemplo de Modelagem UML com a ferramenta ASTAH e-Books UML Essencial: um breve guia para a linguagem pado de modelagem de objetos Fundamentos do Desenho Orientado a Objeto com UML Utilizando UML e pades Principal Referncia James Rumbaugh; Ivar Jacobson; Grady Booch. UML: Guia do Usurio - 2006.

AULA 07 - Modelagem de Classes

Diagrama de Classes

O diagrama de classes na Programao Orientada a Objetos (POO), os problemas so pensados e expressados como objetos, ao contrrio da anlise tradicional os quais eram em rotinas e dados, que aqui foram substitudos por mtodos (comportamento) e atributos (propriedades). Assim, quando colocado o problema de desenvolver um sistema acadmico na anlise orientada a objetos, deve-se pensar como dividir esse problema em objetos. Assim teramos Alunos, Administradores, Professores, Cursos, Turmas, etc... E a melhor maneira de conceituar estes termos considerar um objeto do mundo real e mostrar como podemos represent-lo em termos conceitos em POO. Assim, um objeto um conceito que usamos para representar uma entidade do mundo real. Exemplificando, um Aluno possui nome, data de nascimento, identidade, etc... E alm dessas caractersticas (propriedades), possuem aes (mtodos) como freqentar as aulas, fazer as avaliaes, etc... Em termos de POO para podermos tratar os objetos temos que criar classes. Assim, uma classe representa um conjunto de objetos que possuem comportamentos e caractersticas comuns. Na UML em primeiro lugar denomina-se uma classe e recomenda-se nome-la capitalizando-a e deixando no singular. E em segundo lugar denominam-se as propriedades, informaes especficas relacionadas a uma classe de objeto, isto caractersticas dos objetos que as classes representam. Em terceiro e ltima parte, mtodos, que so aes que os objetos de uma classe podem realizar. Assim tem-se um modelo para instanciar quantos objetos forem necessrios. Dessa forma os objetos instanciados possuiro todas as caractersticas e comportamentos definidos pela classe. Ento as classes especificam a estrutura (propriedades) e os comportamentos (operaes) dos objetos, que so instncias das classes. Geralmente em um sistema de mdio porte sero identificadas diversas classes que compem o sistema. Neste contexto a UML surgiu como uma proposta de ser uma linguagem para modelagem de dados que usava diversos artefatos para representar o modelo de negcio; um destes artefatos o diagrama de classes.

Os diagramas de classes registram atributos e operaes de uma classe e as restries de como os objetos podem ser conectados, descrevendo tambm os tipos de objetos no sistema e os relacionamentos entre eles e esse podem ser associaes e abstraes. Para poder representar a visibilidade dos atributos e operaes, a UML usa os seguintes smbolos: + pblico, visvel em qualquer classe; - privado, visvel somente dentro da classe; # protegido, na classe e suas subclasses. O relacionamento entre classes retrata as relaes entre os objetos. Exemplo: um professor ministra uma disciplina para alunos numa sala. A UML reconhece trs tipos mais importantes de relaes: dependncia, associao e generalizao ou herana. Geralmente as classes no esto isoladas (coesas) e se relacionam entre si (acoplamento). O relacionamento e a comunicao entre as classes se definem em 3 tipos: Associaes que podem ser de Agregao ou Composio; Generalizao ou herana; e Dependncias.

As associaes so relacionamentos estruturais entre instncias e especificam que objetos de uma classe esto ligados a objetos de outras classes, podendo ser unria, binria, etc... As associaes podem existir entre classes ou entre objetos. Uma associao entre a classe Professor e a classe Disciplina (um professor ministra uma disciplina) significa que uma instncia de Professor (um professor especfico) vai ter uma associao com uma instncia de uma Disciplina. Esta relao significa que as instncias das classes so conectadas, seja fisicamente ou conceitualmente. Dependncias so relacionamentos de utilizao no qual uma mudana na especificao de um elemento pode alterar a especificao do elemento dependente. A dependncia entre classes indica que os objetos de uma classe usam servios dos objetos de outra classe. Generalizao ou herana, que pode ser simples ou mltipla (composta), serve para relacionar um elemento mais geral e um mais especfico, onde o elemento mais especfico herda as propriedades e mtodos do elemento mais geral. Como a relao de dependncia, ela existe s entre as classes. Um objeto particular no um caso geral de outro objeto, apenas classes podem receber esse conceito. Agregao um tipo de associao ( parte de ou todo-parte) onde o objeto parte um atributo do todo, onde o objeto parte somente so criados se o todo ao qual esto agregados seja criado. Pedidos composto por itens de pedidos. Composio o relacionamento entre um elemento (o todo) e outros elementos (as partes) onde as partes s podem pertencer ao todo e so criadas e destrudas com ele. Resumindo, temos as seguintes formas de relacionamentos: Generalizao um relacionamento de especializao/generalizao, nos quais os objetos dos elementos especializados (os filhos) so substituveis por objetos do elemento generalizado (os pais).

Associao um relacionamento estrutural que descreve um conjunto de ligaes, em que as ligaes so conexes entre objetos. Agregao um tipo especial de associao representando um relacionamento estrutural entre o

todo e sua parte.

Composio outro tipo especial de associao representando um relacionamento estrutural entre um elemento (o todo) e outros elementos (as partes) onde as parte s podem pertencer ao todo e so criadas e destrudas com ele. Realizao um relacionamento semntico entre classes, em que uma classe especifica um contrato que outra classe garante executar. Dependncia Relacionamento semntico entre duas classes, nos quais a alterao de um (a classe independente) pode afetar a semntica da outra (a classe dependente).

O diagrama de classes lista todos os conceitos do domnio que sero implementados no sistema e as relaes entre os conceitos. Ele muito importante, pois define a estrutura do sistema a desenvolver. O diagrama de classes conseqncia do prvio levantamento de requisitos, definio de casos de usos e classes. Como exemplo tem os passos de elicitao de requisitos com os stakeholders do sistema a ser desenvolvido, usando a tcnica de entrevista com os administradores, professores, etc... que a partir desses os objetos do sistema so definidos: Alunos, Professores, Turmas, Cursos, etc... Definio dos atores do sistema: aluno, professor, administrador, etc... Definio e detalhamento dos casos de uso: Matricular Aluno, Pagar Matrcula, etc... Definio das classes: alunos, professor, etc...

Atributo representa uma propriedade que todos os objetos da classe tm, porm cada objeto ter valores particulares para seus atributos. A UML, o nome de um atributo um texto que deve capitalizar todas as primeiras letras de cada palavra no nome menos a primeira palavra. Todos os mtodos tm que respeitar exatamente a assinatura que composta pelo nome, nmero de parmetros, tipos de dados e ordem. Um mtodo no pode acrescentar ou cortar um parmetro. Para mandar a mensagem corretamente, devesse saber qual a classe do objeto, j que cada classe tendo mtodo com assinatura diferente. Mais uma informao. Devido aos questionamentos de alguns alunos sobre a classificao em relao ao tipo de generalizao, complementei essa aula especificando essa tipificao. Ela pode ser basicamente de dois tipos: Total ou Parcial. Se Total temos para cada ocorrncia da uma classe genrica sempre uma ocorrncia em uma das classes especializadas. Se Parcial temos que nem sempre uma ocorrncia da classe genrica possui uma ocorrncia correspondente em uma classe especializada. Essa tipicao muito interessante para a camada de persistncia e pode ser tambm utilizada na estereotipao de entidades. Para melhor entender segue os exemplos:

Objetos Segundo os pais da UML (Rumbaugh, Jacobson e Booch) um objeto uma instncia de uma classe, isto , trata-se de uma cpia da classe na memria em tempo de execuo (runtime), sendo assim, um elemento especfico que possui valores (estados) nos atributos (campos). A UML representa um objeto usando um retngulo que o representa, onde o nome da instncia do objeto seguido de dois pontos, seguido do nome da classe, com essa formao sublinhada.

dois pontos, seguido do nome da classe, com essa formao sublinhada. Stima atividade baseado no requisito de software da sexta atividade e no diagrama de caso de uso criado na ferramenta Astah, fazer o diagrama de classes para esse UCD. Armazena na ATV7 com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf. Principal Referncia James Rumbaugh; Ivar Jacobson; Grady Booch. UML: Guia do Usurio - 2006.

AULA 08 - Modelagem de Seqncia

Diagrama de Seqncia

O diagrama de seqncia serve para exibir as interaes entre os vrios componentes de um sistema em especial os objetos e como seus mtodos interagem entre si e em qual ordem (seqncia).

O diagrama de comunicao serve para representar os elementos de um sistema que trabalham em conjunto. Esse diagrama expressa essa comunicao, mostrado a troca de mensagens entre os objetos. Ele similar ao diagrama de seqncia, porm mais simples. Os diagramas de seqncia e de comunicao mostram as interaes entre os objetos, por este motivo a UML se refere as estes diagramas como diagramas de interao.

Oita atividade baseado nos requisitos funcionais que se seguem: RF01 - A empresa X necessita de uma aplicao que controle o seu cadastro de seus clientes; o seu cadastro dos tcnicos; e as solicitaes de servios realizadas. RF02 - Para cada cliente so cadastrados os seguintes dados: cdigo (que deve ser gerado automaticamente); o nome; endereo completo com o logradouro, nmero, complemento, bairro, cidade, e estado; e telefones. RF03 - Quando o cliente fizer a primeira chamada por telefone, seus dados devem ser atualizados. Utilizando o ASTAH elabore diagrama de caso, um diagrama de classes e um diagrama de seqncia para os requisitos acima. Observao cada diagrama deve ser gerado na ferramenta citada e copiado para um arquivo PDF. Armazene na ATV8 com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf.

AULA 09 - Modelagem de Atividades

Diagrama de Atividades

O diagrama de atividade exibe a forma que um objeto executa suas aes em um nico processo, representando-os passo a passo, isto , seu fluxo. As atividades que ocorrem em um caso de uso ou no comportamento do objeto seguem a seqncia conforme descrito do diagrama.

Nona atividade baseado na especificao de caso de uso da atividade 8 fazer o diagrama de atividades utilizando o ASTAH. Observao - o diagrama deve ser gerado na ferramenta citada e armazene no ATV9 com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf.

AULA 10 - Modelagem de Estados

Diagrama de Estados

O diagrama de estados tem a finalidade de exibir como um objeto realiza uma determinada operao num determinado momento da execuo, representando um estado particular. Exemplo: um aluno pode estar com a situao de aprovado, aprovado na final ou reprovado.

O smbolo no topo da figura representa o inicio do estado e o smbolo na base da figura representa o fim do estado, entre elas exibido as transies de um estado para outro. Dcima atividade baseado na especificao de caso de uso da atividade 8 fazer o diagrama de estados utilizando o ASTAH. Observao - o diagrama deve ser gerado na ferramenta citada e armazene no ATV10 com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf.

AULA 11 - Modelagem de Componentes

Diagrama de Componentes

O diagrama de componentes mostra a organizao dos componentes na implantao do sistema, mostrando os elementos (componentes) reutilizveis de software e suas interdependncias. Vale salientar que um componente composto por um conjunto de classes, isto , um pakage em Java ou namespace em C#. Na maioria das vezes um componente depende de outros, da mesma forma que as classes que ele possui, dependem das funcionalidades de outras classes do mesmo ou de outro componente. Desta forma o diagrama de componentes mostra esta dependncia. O diagrama de componentes tambm pode servir para exibir a configurao de um projeto de software, expondo a dependncia entre os artefatos que compem o projeto. Assim, as relaes de dependncia servem para informar a finalidade dos diversos artefatos que podem compor o projeto. E esses artefatos podem ser estereotipados para melhor identific-los. Podendo ser um executvel, um pacote, uma tabela, ou qualquer outro tipo de arquivo, estereotipado como documento ou as vezes arquivo.

Dcima primeira atividade baseado na especificao de caso de uso da atividade 8 fazer o diagrama de componentes utilizando o ASTAH. Observao - o diagrama deve ser gerado na ferramenta citada e armazene na ATV11 com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf.

AULA 12 - Modelagem de Distribuio

Diagrama de Distribuio

O diagrama de implantao nos mostra a configurao fsica sobre qual o sistema ser instalado. Esses diagramas servem para exibir a distribuio de hardware do projeto de software, identificando os recursos computacionais como pontos (ns) alm da rede que os relaciona. Dessa forma, esse diagrama permite exibir a topologia de uma rede usada, como tambm os recursos (mquinas).

Dcima segunda atividade baseado na especificao de caso de uso da atividade 8 fazer o diagrama de distribuio utilizando o ASTAH. Observao - o diagrama deve ser gerado na ferramenta citada e armazene na ATV12 com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf.

AULA 13 - Modelagem de Tempo

Diagrama de Tempo O diagrama de tempo serve para exibir a relao de tempo de execuo dos objetos. Esse diagrama foi includo na verso 2.0 para apresentar os comportamento dos objetos e suas interaes em uma escala de tempo, focando as condies que mudam no decorrer desse perodo. Dcima terceira atividade baseado na especificao de caso de uso da atividade 8 fazer o diagrama de tempo utilizando o ASTAH. Observao - o diagrama deve ser gerado na ferramenta citada e armazene na ATV13 com a seguinte identificao instituio_ano_perodo_nome_sobrenome.pdf.

AULA 14 - Exemplificar Modelagem

Exemplo de Anlise e Modelagem Para melhor entender como realizar uma anlise orientada a objetos fazendo uso da Linguagem de Modelagem Unificada, segue um exemplo baseado na necessidade de se controlar as solicitaes de servios da empresa ABC. Especificao de Requisitos Funcionais RF01. A empresa ABC necessita de uma aplicao que controle: o seu cadastro de seus clientes; o seu cadastro dos tcnicos; e as solicitaes de servios realizadas. RF02. Para cada cliente so cadastrados os seguintes dados: cdigo (que deve ser gerado automaticamente); o nome; endereo completo com o logradouro, nmero, complemento, bairro, cidade, e estado; e telefones. RF03. Quando o cliente fizer a primeira chamada por telefone, seus dados devem ser atualizados. RF04. Para o tcnico deve se cadastrar: o nome; o CPF; endereo residencial completo; telefones; e data de admisso. Quando o tcnico for desligado da empresa, deve se cadastrar a data da resciso contratual.

RF05. Quando o cliente solicitar um atendimento, deve-se cadastrar a identificao do cliente; a data e hora da solicitao; e o problema a ser solucionado; o status da solicitao deve ficar em S que significa Solicitado.

solicitao; e o problema a ser solucionado; o status da solicitao deve ficar em S que significa Solicitado. RF06. Aps a solicitao realizada ela deve ser atendida por um dos tcnicos colocando a mesma no status A de atendimento e informando qual o tcnico est fazendo esse atendimento, sendo registrado a data e hora do incio do atendimento. RF07. Depois de realizado o atendimento o cliente deve ser avisado sobre o parecer deste escrito pelo tcnico e o status dever passar para E de encerrado sendo registrada a data e hora do encerramento. RF08. Caso alguma irregularidade ocorra nessa solicitao, o status dever passar para C que indica cancelado, registrando o motivo do cancelamento. Diagrama de Casos de Uso

Especificao Resumida de Casos de Uso Caso de Uso Consultar Cliente Consultar Cliente Cdigo: UC01 Nome: Consultar Cliente Descrio: Tem a finalidade de exibir os clientes cadastrados possibilitando as opes de incluso, alterao e excluso. Ator: Administrador Fluxo Principal 1. Exibio de lista de todos os clientes cadastrados. 2. Oferece ao usurio: 2.1. Selecionar um cliente, para alterar seu cadastro; 2.2. Localizar um cliente ou conjunto de clientes por meio de pesquisa; 2.3. Escolher a opo de inserir cliente. 3. Pesquisar. cliente 3.1. Encontrar cliente atravs do nome ou parte dele. 3.2. O sistema exibe a lista de clientes que satisfao ao critrio, exibindo: 3.2.1. Cdigo de identificao; 3.2.2. Nome do cliente; 3.2.3. Telefone. 4. Insero de Cliente 4.1. Include Caso de Uso Manter Cliente 5. Seleo de Cliente 5.1. Selecionar um cliente habilitando as opes de Alterar Cliente e Excluir Cliente. 5.2. Se selecionado usar Include Caso de Uso Manter Cliente. Diagrama de Classes

Diagrama de Estados

Guias de Referncia UML Guia Bsico sobre UML Modelagem UML Ferramenta para Modelagem Astah Manual do Astah Astah Community Astah UML Astah Profissional Astah Share Plugins

>>> Diversos para NetBeans 6.9 >>> Modelagem UML no NetBeans 6.9 AULA 15 - Padres de Projeto
O que Padro de Projeto

Um padro a soluo para um determinado problema em um determinado contexto. Um padro codifica conhecimento especfico obtido em uma experincia em um determinado domnio. Um sistema bem estruturado estar cheio de padres: Idiomas; Padres de projeto; e Padres arquiteturais. Por que usar Padro de Projeto? Podem ser utilizados para melhorar o entendimento ou comunicao dos problemas e decises arquiteturais. (Fowler) Podem ser vistos como uma tentativa de criar um vocabulrio comum para comunicao. (Fowler) Experincia coletiva de arquitetos e engenheiros de software habilidosos e experientes. (Buschmann et al.) Especialistas j possuem solues para muitos dos problemas recorrentes. (Buschmann et al.) Padres capturam solues comprovadas de uma forma facilmente acessvel. (Buschmann et al.) Padres do suporte tanto aos novatos quanto aos especialistas em desenvolvimento de software (Buschmann et al.) Quais os Padres de Projeto? Gamma et al descrevem vinte e trs padres que podem ser utilizados em praticamente qualquer rea de programao. Estes padres se tornaram clssicos da orientao a objetos. Eles foram utilizados por muitos programadores muito antes do lanamento deste livro. Mas no tinham sido sistematicamente documentados e catalogados. Os padres de Gamma et al so chamados de padres da gangue dos quatro (Gang of Four patterns, ou apenas GoF). Outro padro muito conhecido o GRASP, sigla de General Responsability Assignment Software Patterns. ou Padres que descrevem os princpios fundamentais do design orientado a objetos e a atribuio de responsabilidades. Qual o template de um Padro? Nome - o nome que serve como referencia para o padro; Problema - explica o problema que ocorre em um contexto, com sintomas e em condies; Soluo - elementos que constituem o design, seus relacionamentos, responsabilidades e colaboraes; Conseqncias - resultados e compromissos decorrentes da aplicao do padro. Impactos sobre a flexibilidade, extensibilidade, portabilidade ou desempenho do sistema. Fundamentam a escolha do padro mais apropriado; Nome e Classificao - identificam unicamente o padro e o classifica para catalogao; Inteno - uma breve descrio que deve responder o que o padro faz, qual sua inteno e que problema ele trata; Tambm Conhecido Como - outros nomes pelo qual o padro conhecido; Motivao - um cenrio que ilustra o problema e como as classes deste padro o solucionam; Aplicabilidade - em que situaes o padro pode ser aplicado; Estrutura - representao grfica do padro com suas classes e colaboraes; Participantes - classes e objetos que participam no padro, incluindo suas responsabilidades; Colaboraes - como os participantes colaboram entre si; Conseqncias - como o padro atende a seus objetivos e que efeitos colaterais seu uso pode provocar; Implementao - dicas, tcnicas e erros comuns ao implementar este padro; Exemplo de Cdigo - fragmentos de cdigo ilustrando o padro; Usos Conhecidos - exemplos de uso do padro em sistemas reais; e Padres Relacionados - padres que esto fortemente relacionados a este , incluindo suas diferenas, ou utilizados por este. Quais as categorias de Padres? Existem basicamente 3 categorias, as criacionais, estruturais e comportamentais. Padres Criacionais: auxiliam na criao de objetos, tornando o programa menos dependente do modo como os

objetos so criados e compostos. Assim, estes padres permitem que se mude as classes dos objetos criados em tempo de execuo com pouco esforo de programao; Padres Estruturais: Descrevem formas flexveis para compor classes e objetos; e Padres Comportamentais: Estes padres so relacionados a algoritmos e responsabilidades associados a cada objeto. Mudando-se os objetos e classes utilizados, pode-se mudar o comportamento do programa. Acoplandose um objeto a outro, pode-se adicionar comportamento ao segundo objeto. Quais os critrios de Padres? Os padres de projeto so classificados por dois critrios, o de objetivo e o de escopo. Objetivo, refletem as categorias (criao, de estrutura ou de comportamento). Escopo, especifica quando o padro aplicado (classes ou a objetos). Padres com escopo de classe lidam com relacionamentos estabelecidos atravs de herana, ou seja, estticos e definidos em tempo de compilao. Padres com escopo de objeto lidam com relacionamentos de objeto, que podem ser modificados em tempo de execuo e so mais dinmicos. Praticamente todo padro utiliza herana de alguma forma, por isto apenas os padres que focam em relacionamentos atravs de herana devem ser classificados com escopo de classe. Os padres mais importantes esto em escopo de objeto. Principal Referncia Erich Gamma, et al. Padres de Projeto - 2008. Biografias Erich Gamma. Saber mais. Martin Fowler. Saber mais. Craig Larman. Saber mais. Links Wiki Padres de Projeto Wiki Design Patterns Wiki Categorias de Programao Orientada a Objetos Wiki Categorias de Padres de Projeto de Software Book Design Patterns Overview of Design Patterns Volume 1 Overview of Design Patterns Volume 2 Overview of Design Patterns Volume 3 Software Design Patterns OO design, Java, C++ General Responsibility Assignment Software Patterns (GRASP) e-Books GAMMA, Erich; et al. Padres de Projeto. So Paulo: Bookman, 2008.

AULA 16 - Padro GRASP

General Responsability Assignment Software Patterns (GRASP) Os padres GRASP descrevem os princpios fundamentais do design orientado a objetos e a atribuio de responsabilidades, expressos como padres. Estes padres servem como guia para a realizao de um design baseado em atribuio de Responsabilidades (RDD). Existem nove padres GRASP: 1. 2. 3. 4. Creator Information Expert Low Coupling Controller

4. 5. 6. 7. 8. 9.

Controller High Cohesion Polymorphism Pure Fabrication Indirection Protected Variations

1. Creator Designar responsvel por criar uma nova instncia de uma determinada classe. Problema: Quem deve ser o responsvel por criar uma nova instncia de uma determinada classe? Soluo: Atribui-se a classe B a responsabilidade para criar uma instncia da classe A se alguma das situaes acontecer: B contm ou agrega objetos do tipo A; B armazena instncias do tipo A; B, de forma privada, usa objetos do tipo A; B tem os dados de inicializao que iro ser passados para A quando ele criado; e Dessa forma, B um Expert em relao a criao de A. Se mais de uma opo se aplica, d preferncia a classe que agrega ou contm instncias de A Creator Errado Creator Certo

2. Information Expert

Atribuir responsabilidades para classes que possuem a informao necessria. Problema: Qual o princpio bsico para se atribuir responsabilidades a objetos? Soluo: Atribuir responsabilidades para classes que possuem a informao necessria. Exemplo: Numa aplicao de Controle de Vendas, qual classe deve ter a responsabilidade de prover a informao do total de uma venda? Information Expert Errado Information Expert Certo

3. Low Coupling Atribuir a responsabilidade de forma que o acoplamento permanea baixo. Problema: Como dar suporte a baixa dependncia, reduo de impacto de mudanas e aumento do reuso? Soluo: Atribuir a responsabilidade de forma que o acoplamento desnecessrio permanea baixo. Mas o que acoplamento? a medida de o quo forte um elemento est conectado, tem conhecimento ou depende de outros elementos. Um elemento (classe, subsistema, etc.) com baixo acoplamento no dependente de muitos outros elementos, provendo aumento nas possibilidades de reuso, baixa manuteno, etc. Low Coupling Errado

4. Controller Delegar trabalho a outros objetos, executando pouca lgica em si. Problema : Qual o primeiro objeto aps a Interface de Usurio que receber e coordenar a operao do sistema?

Soluo : Atribuir essa responsabilidade a uma classe representando uma das opes: Classe que representa todo o sistema (aconselhvel somente em situaes em que existem poucos operaes de sistema), servios de um mdulo ou subsistema ou qualquer outra variao de facade controller; e Classe que representa um cenrio de caso de uso no qual o evento do sistema acontece. Normalmente o objeto definido pelo GRASP controller delega o seu trabalho a outros objetos, executando pouca ou nenhuma lgica em si. Adicionalmente este objeto no deve ser uma classe persistente do sistema. Controler Certo

5. High Coesion Atribuir responsabilidade de forma que a coeso permanea alta. Problema: Como manter os objetos focados, fcies de entender, gerenciveis e ainda pouco acoplados? Soluo: Atribuir responsabilidade de forma que a coeso, ou, mais especificamente, coeso funcional, permanea alta. O que coeso ? a medida de quo forte esto relacionadas e focadas as responsabilidades de um elemento. Um elemento com alta coeso, indica que suas responsabilidades so realizadas com pouco esforo. Por outro lado, um elemento com baixa coeso est muito distante, desassociado, dos outros elementos, gerando maior esforo para que ele cumpra suas responsabilidades.

6. Polymorphism Quando comportamentos relacionados variam entre classes. Problema: Como tratar alternativas baseadas em tipo? Como criar componentes de software plugveis? Soluo: Quando alternativas ou comportamentos relacionados variam por tipo (classe), atribuir a responsabilidade ao comportamento usando operaes polimrficas para os tipos nos quais o comportamento varia. Nunca execute teste pelo tipo de um objeto e utilize lgica condicional para variar o comportamento baseado neste tipo.

7. Pure Fabrication Atribuir responsabilidades altamente coesas a uma classe que no representa um conceito no domnio do problema. Problema: Que objetos devem possuir responsabilidades quando no se quer violar os padres High Coesion e Low Coupling, uma vez que a soluo oferecida pelo Information Expert no adequada? Soluo: Atribuir um conjunto de responsabilidades altamente coesas a uma classe artificial ou conveniente que no

Soluo: Atribuir um conjunto de responsabilidades altamente coesas a uma classe artificial ou conveniente que no representa um conceito no domnio do problema. Tal classe uma criao da imaginao para suportar alta coeso, baixo acoplamento e reuso.

8. Indirection Atribuir a responsabilidade a um intermedirio que ir mediar entre os demais componentes de forma que eles no sejam diretamente acoplados. Problema: Onde atribuir uma responsabilidade para evitar acoplamento direto entre duas ou mais entidades? Como desacoplar objetos de forma que baixo acoplamento seja suportado e que o potencial de reuso permanea alto? Soluo: Atribuir a responsabilidade a um objeto intermedirio que ir mediar entre os demais componentes ou servios de forma que eles no sejam diretamente acoplados.

9. Protected Variations

Identificar pontos de variaes ou instabilidade previsveis e atribuir responsabilidades para criao de uma interface estvel em torno desses pontos. Problema: Como projetar objetos, sub-sistemas e sistemas de forma que as variaes ou instabilidades nestes elementos no impliquem em impacto indesejado sobre outros elementos? Soluo: Identificar pontos de variaes ou instabilidade previsveis. Atribuir responsabilidades para criao de uma interface estvel em torno desses pontos.

AULA 17 - Padro GoF

O que Padro GoF? Gamma et al descrevem vinte e trs padres que podem ser utilizados em praticamente qualquer rea de programao. Estes padres se tornaram clssicos da orientao a objetos e so chamados de padres da gangue dos quatro (Gang of Four patterns, ou apenas GoF).

Esse padro se divide em dois critrios: Critrio Objetivo que refletem as categorias de criao, estrutura e comportamento, por sua vez esse critrio se divide em trs categorias. Categoria dos Criacionais usados para determinar como os objetos so criados; Categoria dos Estruturais que descrevem formas flexveis para compor classes e objetos; e a Categoria dos Comportamentais relacionados aos algoritmos e responsabilidades associados a cada objeto. O Critrio Escopo que especifica quando o padro aplicado a classe e/ou objeto. Como pode ser visto logo abaixo.

AULA 18 - Padro GoF Criacionais

Padro de Projeto GoF Criacionais Padres criacionais so usados para determinar como os objetos sero criados ou instanciados. 1. Abstract Factory Encapsular um conjunto de fbricas que produzem anlogas famlias de objetos.

2. Builder Encapsular a construo de objetos complexos a partir de sua representao, por isso, o processo de construo mesmo pode criar vrias representaes, especificando apenas o tipo de contedo.

3. Factory Method Permitir subclasses decidirem que classe instanciar.

4. Prototype Criar uma instncia inicializada para clonar ou copiar.

5. Singleton Certifica que apenas uma nica instncia de uma classe possa existir, fornecendo um mtodo nico de acesso a ela.

AULA 19 - Padro GoF Estruturais

Padro de Projeto GoF Estruturais Padres estruturais que descrevem as formas para relacionar as classes e objetos.

Padres estruturais que descrevem as formas para relacionar as classes e objetos. 1. Facade Define uma interface de alto nvel.

2. Adapter Adaptar uma interface para uma interface esperada.

3. Bridge Dissociar uma interface de sua implementao.

4. Composite Criar uma estrutura de rvore de hierarquias parte-todo.

5. Decorator Estender a funcionalidade dinamicamente.

6. Flyweight Suporte objetos finos de forma eficiente atravs de compartilhamento.

7. Proxy Representar um objeto com outro objeto para controle de acesso.

AULA 20 - Padro GoF Comportamentais

Padro de Projeto GoF Comportamentais Padres comportamentais so relacionados aos algoritmos e responsabilidades associados a cada objeto. 1. Chain of Responsability Define um mtodo de passar um pedido, entre uma cadeia de objetos.

2. Command Encapsular um pedido de comando em um objeto.

3. Interpreter Permitir a incluso de elementos de linguagem em um aplicativo.

4. Mediator Define comunicao simplificada entre classes.

5. Memento Salvar e restaurar o estado interno de um objeto.

6. Observer Define um regime de notificao de objetos de mudanas para um outro objeto.

7. State Alterar o comportamento de um objeto quando seu estado muda.

8. Strategy Encapsular um algoritmo dentro de uma classe.

9. Template Method Permite subclasses redefinir os passos de um algoritmo.

10. Visitor Define uma nova operao em uma classe sem troc-la.

AULA 21 - Padres Arquiteturais de Software

AULA 21 - Padres Arquiteturais de Software

Padro de Arquitetura de Software MVC Visa separar a lgica do negcio da lgica da apresentao, permitindo o desenvolvimento, teste e manuteno isolado. O model (domnio) usado para definir e gerenciar o domnio da informao e notificar observadores sobre mudanas nos dados; O view (apresentao) apresenta o modelo num formato adequado ao utilizador; e O controller (regras) recebe a entrada de dados e inicia a resposta ao utilizador ao invocar objetos do modelo. Exemplo: aluno, professor e turma fazem parte do domnio de um sistema acadmico. Operaes como calcular a mdia final do aluno ou o ndice de faltas da turma fazem parte da lgica de domnio. A forma como o dado armazenado de responsabilidade do modelo. Caso Prtico: uma aplicao web em que a viso um documento HTML. O controlador recebe uma entrada GET ou POST aps um estmulo do utilizador e decide como process-la, invocando objetos do domnio para tratar a lgica de negcio, e por fim invocando uma viso para apresentar a sada. A associao direta um relacionamento que descreve um conjunto de vnculos, onde cada vnculo definido como uma conexo semntica entre objetos. A associao indireta um relacionamento entre elementos, um independente e outro dependente.

Uma utilizao do padro arquitetural MVC seria da seguinte forma: a camada View seriam as pginas ASPX ou JSP, a camada Model seriam as classes de domnio da aplicao e a camada de Controller seriam as classes com as regras de negcio. Porm, no foi essa a utilizao original idealizada para o MVC quando criado para ser aplicada na linguagem Smalltalk. Nessa o usurio interage com a interface de alguma maneira no View, o Controller manipula o evento do usurio, dai acessa o Model acessando as classes de cadastro.

AULA 22 - Laboratrio de Programao Orientada a Objetos

Exemplo de Codificao POO Clique aqui para download de exemplo em CSharp Clique aqui para download de exemplo em Java Clique aqui para download de exemplo em Phyton Introduo Caros alunos de LABPOO, segue a lista de artefatos que devem ser produzidos para a primeira avaliao e que vem ser postados no repositrio do projeto at a data da AV1: Glossrio de Negcios (principais termos do negcio); Documento de Viso; Documento de Especificao de Requisitos de Software (requisitos funcionais e no funcionais); Planilha de Contagem de Pontos de Funo (s os pontos no ajustveis); Diagramas de Casos de Uso (para os principais requisitos); Especificao de Casos de Uso (para os UCD modelados); e Diagrama de Classes (para as classes de domnio da aplicao). Obs1: Em um sistema real a quantidade de artefatos imensamente maior, mas como aqui o objetivo fazer vocs terem contato com o que se deve ser feito, estamos fazendo o estritamente necessrio. Obs2: A nota da AV1 ser baseada na qualidade dos artefatos produzidos (avaliao subjetiva do professor). Obs3: Aps a AV1 iremos iniciar a segunda fase com as aulas de programao orientada a objetos (Java e/ou CSharp) com o desenvolvimento do projeto baseado nos artefatos produzidos a primeira fase Repositrio do projeto: http://www.4shared.com/dir/1fc7vpx0/FIR20111-OSWEB.html

Repositrio do projeto: http://www.4shared.com/dir/1fc7vpx0/FIR20111-OSWEB.html Verdades no to conhecidas sobre programao - Este artigo a traduo de um excelente texto escrito por David Veksler, no qual ele conta o que sua experincia como programador lhe ensinou. E vamos ao que interessa: Um programador gasta cerca de 10% a 20% do seu tempo escrevendo cdigo. Normalmente escreve entre 10 e 12 linhas por dia, que estaro presentes no produto final independentemente do seu nvel de percia ou experincia. Bons programadores gastam cerca de 90% do seu tempo pensando, pesquisando e experimentando maneiras de encontrar a soluo tima. Os programadores ruins gastam quase 90% do tempo debugando e fazendo alteraes muitas vezes aleatrias na tentativa de fazer funcionar. Um bom programador dez vezes mais produtivo do que um programador comum. Um excelente programador entre 20 e 100 vezes mais produtivo do que um convencional. No um exagero. Estudos desde os anos 60 tm mostrado isso consistentemente. Um mau programador no s improdutivo - alm de no concluir o trabalho com xito, gera dores de cabea e trabalho extra para outras pessoas consertarem. Excelentes programadores gastam pouco do seu tempo escrevendo (cdigo que de fato estar no resultado fin al). Os programadores que gastam muito do seu tempo escrevendo provavelmente no esto encontrando e utilizando solues existentes para problemas antigos. Bons programadores so timos em reconhecer e em reutilizar padres comuns e no tm medo de refatorar seu cdigo constantemente, a fim de atingir a soluo tima. Programadores ruins escrevem cdigo que falha em integridade conceitual, no-redundncia, hierarquia e padres, tornando complicada a refatorao, fazendo com que seja mais fcil jogar fora todo o trabalho e recomear. Software, como qualquer coisa, obedece s leis da entropia. Contnuas mudanas levam ao desgaste do software e de sua integridade conceitual planejada originalmente. A entropia inevitvel, no entanto, programadores que falham ao estabelecer a integridade conceitual criam sistemas que se desgastam to rapidamente, que muitas vezes se tornam inteis e caticos demais mesmo antes de serem concludos. Possivelmente, o motivo mais comum para falha em projetos o rompimento da integridade conceitual devido entropia descontrolada (o segundo mais comum a entrega de um produto diferente do que o cliente esperava). A entropia desacelera exponencialmente o desenvolvimento e o principal motivo para deadlines desesperadoras. Um estudo realizado em 2004 revelou que 51% dos projetos falham ou iro falhar em alguma funcionalidade importante e que 15% simplesmente vo falhar como um todo, o que um grande avano desde 1994, quando 31% dos projetos falhavam criticamente. Embora muitos softwares sejam desenvolvidos em equipe, no se trata de uma atividade democrtica. Geralmente somente uma pessoa responsvel pelo design do sistema e o resto do time o completa com detalhes. Programar um trabalho pesado. uma atividade mental intensa. Bons programadores pensam sobre seu trabalho 24/7. Eles escrevem seu cdigo mais importante no chuveiro, sonhando etc., porque o trabalho mais importante feito longe do teclado. Projetos no so concludos mais rapidamente gastand o mais tempo no escritrio ou adicionando pessoas novas ao projeto. Um excelente operrio pode ser duas ou at trs vezes mais produtivo que um operrio comum, j um bom programador pode fazer com que seu trabalho seja mais do que 10 mil vezes mais produtivo do que um programador comum - Bill Gates Link para aulas de Java Link para aulas de CSharp 10 passos para uma boa programao 1 - Programar visando uma boa indentao, isso lhe garante estruturao fcil e boa noo quando precisamos saber se blocos de cdigos esto aninhados ou no.

se blocos de cdigos esto aninhados ou no. 2 - Preservar pro padres em variveis, nunca usar a seguinte nomenclatura, nomeVariavel1, nomeVariavel2 ou seja enumerar variveis fica bastante difcil pra voc saber o qual estado da varivel ou qual finalidade ela tem 3 - Preservar Uma boa logica em seus fluxos alternativos, ou condies, como if e case, sendo estes clssicos para qualquer linguagem e determinante para suas regras de negocio sempre bom usar ambos com cuidado e com planejamento para que estes sejam bem legveis e intuitivos para outras pessoas. 4 - Minimizar suas interaes, ou seja, sempre que usar algum lao de repetio sempre organiza-lo, calcula-lo, para que este seja feito simples e que venha atender seu proposito sem atingir loop infinito, nem que venha dificultar o seu prprio intendimento. 5 - Comentar suas regras de negocio, ou seja, blocos com grande complexidade e regras de seu sistema sempre precisa ser comentado para que seja intendivel, para que o programador que veja seu cdigo entenda facilmente o que voc escreveu, e o que acontece neste trecho de cdigo. OBS.: Nem sempre bom comentar tudo apenas o necessrio para que o condigo no fique sujo com todos os comentrios. 6 - No caso de Um projeto estruturado sempre modularizar este para que seus modulos sejam facilmente encontrados para futuras alteraes ou crescimento, No caso de um projeto OO sempre seguir um bom diagrama de classe utilizando os pilares da POO como herana, polimorfismo, encapsulamento e abstrao. 7 - Documentar seu projeto independente do tamanho do mesmo para que haja um manual do mesmo para que haja uma analise de riscos no mesmo para futuras alteraes. 8 - Testas se suas solues so as melhores aplicveis, porqu se um problema foi resolvido no quer dizer que sua soluo foi a melhor pra este caso visto que pessoas podem ter encontrado o mesmo problema e resolvido de forma fcil e bem estudada. 9 - Pesquisar melhoras e padronizar seus cdigos, para que todos em seu meio ambiente programem similar a voc para que haja uma fcil integrao no projeto e que seja bem intuitiva a analise deste visto que todos possuem a mesma viso. 10 - Trocar sempre experincias com outros programadores para que seja adquirido ou repassado conhecimento para que erros sejam minimizados ao mximo em seus projetos.

AVALIAES
Avaliao Simulado para AV1 Simulado para AV2 Simulado para AV2 - Gabarito Respostas do simulado AV1 Gabarito da AV1 2011-1 Tipo Objetiva Gabarito da AV1 2011-1 Tipo Subjetiva Gabarito da AV2 2011-1 Tipo Objetiva Gabarito da AV2 2011-1 Tipo Subjetiva Guias Avaliao da Organizao de Desenvolvimento.dot Avaliao da Organizao-alvo.dot Avaliao de Iterao.dot Avaliao de Status.dot Caso de Desenvolvimento.dot Caso de Negcios.dot Documento de Arquitetura de Negcios.dot Documento de Arquitetura de Software.dot Especificao de Caso de Uso de Negcios Nome do Caso de Uso de Negcios.dot Especificao de Caso de Uso Nome do Caso de Uso.dot

Especificao de Caso de Uso Nome do Caso de Uso.dot Especificao de Realizao de Casos de Uso Nome do Caso de Uso de Negcios.dot Especificao de Realizao de Casos de Uso Nome do Caso de Uso.dot Especificao dos Requisitos de Software Para Subsistema ou Recurso.dot Especificao dos Requisitos de Software.dot Especificao Suplementar de Negcios.dot Especificao Suplementar.dot Glossrio de Negcios.dot Glossrio.dot Guia de Design.dot Guia de Modelagem de Casos de Uso.dot Guia de Modelagem de Negcios.dot Guia de Programao.dot Guia de Referncia de Convenes de Codificao Java.pdf Guia de Teste.dot Guia da UML Lista de Materiais.dot Lista de Riscos.dot Notas de Release.dot Plano de Aceitao do Produto.dot Plano de Desenvolvimento de Software (Projeto Pequeno).dot Plano de Desenvolvimento de Software.dot Plano de Garantia de Qualidade.dot Plano de Gerenciamento de Configurao.dot Plano de Gerenciamento de Requisitos.dot Plano de Gerenciamento de Riscos.dot Plano de Implantao.dot Plano de Integrao do Build.dot Plano de Iterao.dot Plano de Mtricas.dot Plano de Resoluo de Problemas.dot Plano de Teste.dot Regras de Negcios.dot Solicitaes dos Principais Envolvidos.dot Sumrio de Avaliao de Testes.dot Viso (Projeto Pequeno).dot Viso do Negcio.dot Viso.dot Outras referncias sobre anlise e projeto orientado a objetos Aprenda Programao Orientada a Objetos em 21 Dias Engenharia de Software Sommerville 6a.Edio Engenharia de Software Sommerville 8a.Edio Engenharia de Software Teoria e Prtica Fundamentos do Desenho Orientado a Objetos com UML Padres de Projeto Padres e Projeto Orientado a Objetos UML Essencial Prof. lvaro Pinheiro MSc. em Engenharia de Software pelo CESAR Coordenador do Ncleo de Sistemas da Procuradoria Geral do Estado de Pernambuco Analista de Aplicao da Agncia Estadual de Tecnologia da Informao de PE http://www.wix.com/alvarofpinheiro/pessoal

Details

1239
Since 08 Feb 2011

Acessos

Acessos