Parte i Cap. 1 – Enquadramento e

8/14/2019 Parte i Cap. 1 Enquadramento e

1/35

PARTE ICAP. 1 ENQUADRAMENTO E CONCEITOS GERAIS1.1. IntroduoO objectivo deste livro apresentar a linguagem de modelao UML e demonstrar a sua aplicaode forma a facilitar todo o desenvolvimento de software, quer seja directamente como tcnica demodelao de software quer seja na sua utilizao em metodologias de desenvolvimento ou emferramentas de apoio.

1.2. O Impacto das Tecnologias de InformaoActualmente, as tecnologias de informao encontram-se na origem de mudanas significativasao nvel dos modelos de negcio das empresas, e constituem um elemento fundamental para aobteno de vantagens estratgicas e competitivas.A implementao de sistemas de informao requer um investimento significativo (financeiro,tecnolgico e de recursos humanos), pelo que estas intervenes devero merecer apoio ecomprometimento das administraes.Muito gestores no percebem por questes de formao e os tcnicos de informtica criaramimagem muito tcnica. Isto contribui para a no considerao da informtica como uma reaestratgica dentro da empresa.

A progressiva importncia que os sistemas de informao tm nas organizaes pode serconstatada atravs de diversas situaes:- No passado era comum o responsvel da informtica depender hierarquicamente do directorfinanceiro. Actualmente a rea de informtica est ao mesmo nvel que os restantesdepartamentos.- A indstria de software actualmente uma das mais importantes de todo o planeta- A crescente importncia das empresas relacionadas com a Nova Economia levou ao Nasdaq- A importncia destas empresas tem motivado a crescente preocupao dos governos emgarantir o acesso livre ao mercado e a tentar evitar posies monopolistas.

1.3. Produto e ProcessoA importncia das tecnologias de informao na nossa vida sobretudo concretizada pelas

funcionalidades que so implementadas ao nvel do software, e que so disponibilizadas com osuporte de um conjunto de dispositivos diversos (hardware). O primeiro pode ser considerado ocomponente lgico dos sistemas de informao, o segundo o componente fsico.No existe uma definio rigorosa e inequvoca de software. para alguns o resultado final de umprocesso, ao qual designam por Engenharia de Software.Se pensarmos que o desenvolvimento do software um processo que deve ser baseado naaplicao de tcnicas e prticas rigorosas, sistemticas, eficientes e controlveis, como nasoutras engenharias. Pressupe tambm a utilizao de ferramentas de apoio a todo o processo.As caractersticas destas ferramentas podem ter um impacto aprecivel no produto final.No entanto de referir que a produo de software encerra em si mesma alguma subjectividade.Neste aspecto o processo mais de uma actividade artstica. Podemos considerar pois que o pontode equilbrio correcto depende de cada caso, mas deve-se encontrar a meio caminho entre a

aplicao de tcnicas estruturadas (Engenharia) e introduo de factores de criatividade.So caractersticas fundamentais do software:- Flexibilidade: capacidade de evoluo face aos requisitos de negcio- Fiabilidade- Implementao das necessidades das organizaes- Nvel de desempenho adequado- Facilidade de utilizao

1.4. Sistemas de InformaoA viso mais tradicional que software um conjunto de programas mais a respectivadocumentao.O conceito mais abrangente de sistemas de informao um conjunto integrado de recursos(humanos e tecnolgicos) cujo objectivo satisfazer adequadamente a totalidade dasnecessidades de informao de uma organizao e os respectivos processos de negcio


2/35


3/35

1995 Vantagem competitiva Tecnologias OO; suporte deciso; gesto do conhecimento2000 Driver do negcio Internet; computao ubquaExiste um conjunto de razes que levam as organizaes a investir em SI:- Reduzir custos operacionais- Satisfazer requisitos de informao dos utilizadores- Contribuir para a criao de novos produtos e servios- Melhorar o nvel de servio prestado

- Melhorar e automatizar a relao com os parceiros de negcio- melhorar o desempenho de pessoas e mquinas

1.7. Problemas no Desenvolvimento de Sistemas de InformaoHistoricamente, o software tem apresentado de forma sistemtica e contnua os mesmosproblemas. Se pensarmos no impacto nas organizaes temos 3 nveis:- Falta de qualidade: satisfao incompleta dos requisitos e problemas ps instalao- Desvios nos Prazos- Custos previamente definidos ultrapassadosDaqui nasceu a famosa crise no software da dcada de 70 que foi reforada por Fred Brooks noclebre artigo No Silver Bullets.Os problemas referidos so durante o processo de desenvolvimento, mas igualmente graves soos que acontecem aps a instalao e entrada em produo.Podem ter impacto em 2 reas crticas: questes financeiras e vidas humanas.Diversas causas esto na origem deste crnico falhano:- Falta de empenhamento dos rgos de topo- Falta de comprometimento e empenhamento dos utilizadores- Incompreenso do valor dos SI- Falta de entendimento e de sintonia entre informticos e clientes utilizadores no mbito dosrequisitos do mesmo- Deficincias vrias no processo de desenvolvimento- Falhas na coordenao do projecto- falta de qualidade e inadequao dos recursos envolvidos

- Mudanas frequentes dos requisitos do negcio- Dificuldades na integrao de componentes- Qualidade e desempenho deficientes do software- Incapacidade de identificar e controlar os riscos do projecto

1.8. Planeamento Estratgico de Sistemas de InformaoNo passado os SI eram s para melhorar eficincia. Hoje concentram-se na obteno devantagens competitivas.Um dos objectivos dos SI a satisfao adequada dos requisitos de negcio, garantindo assim ocorrecto alinhamento com a estratgia da organizao. esse o mbito do Planeamento Estratgico de SI, que define componentes e funciona comoguia. aqui devem ser identificadas e prioritizadas as aces a desencadear para atingir a situao

futura proposta. S depois se avana para a Engenharia de Software.Podemos definir o PESI como um processo cuja finalidade garantir o alinhamento dos SI com osobjectivos do negcio. Este processo tem fases:Levantamento dos Objectivos Estratgicos --> Anlise detalhada do negcio --> Anlise dasituao actual dos SI --> Proposta de situao futura dos SI --> Planeamento da Implementao.

1.9. Engenharia De SoftwareUma das primeiras definies foi dada por Fritz Bauer nos finais da dcada de 60 como sendo adefinio e utilizao de princpios de engenharia slidos, de modo a desenvolver softwareeconmico, fivel e que trabalha eficientemente em mquinas reais. Inclui pois um conjunto demtodos, de ferramentas e procedimentos.Uma das mais usadas a do IEEE: a aplicao de um processo sistemtico, disciplinado, equantificado ao desenvolvimento, operao e manuteno de software.As actividades associadas Engenharia do Software podem ser agrupadas em 3 grandes fases:- Concepo


4/35

- Implementao- ManutenoConceitos a saber: sistemas de informao; arquitecturas; planeamento estratgico; engenhariado software.


5/35

CAP. 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE2.1. IntroduoA produo de software frequentemente uma actividade no estruturada, por vezes catica, semorientaes de natureza estratgica e sem planos de gesto e controle (build and fix programare corrigir).Roger Pressman apelidou de 4 Ps associados ao desenvolvimento de software:- Pessoas motivadas e comprometidas

- Processo com tcnicas e regras bem definidas- Produto de qualidade respondendo s necessidades dos utilizadores.- Projecto credvel e controladoEm 1996 Barry Boehm identificou 7 questes que qualquer projecto deve responder (W5H2):- Porque que o sistema vai ser desenvolvido (Why)?- O que vai/deve ser feito (What)?- Quando que vai se feito (When)?- Quem o responsvel (Who)?- Onde que as responsabilidades esto localizadas (Where)?- Como que vai ser feito (How)?- Quanto vai custar em termos de recursos (How much)?

2.2. Processos e MetodologiasO processo de desenvolvimento de software um conceito de mbito muito vasto e pretendedesignar uma sequncia de actividades, normalmente agrupadas em fases e tarefas, que soexecutadas de forma sistemtica e uniformizada, por intervenientes com responsabilidades bemdefinidas e que a partir de um conjunto de inputs produzem um conjunto de outputs. Tem 4objectivos fundamentais:- Providenciar orientao sobre a sequncia de actividades- Especificar os modelos descritivos do sistema que devem ser desenvolvidos- Dirigir as tarefas dos participantes/equipa- Providenciar critrios para monitorizao.O conceito de metodologia acrescenta a esta definio a utilizao de um conjunto de

ferramentas, tcnicas e notaes, para alm de diversos princpios e regras mais prticas:- Regras de elaborao de estimativas (custos, prazos)- Tcnicas para efectuar medies- Procedimentos a seguir de forma a garantir qualidade- Programas de formao- Modelos de documentaoO conceito de ciclo de vida pode ser encarada como sinnimo de processo.No UML e outras processo afinal metodologia.Em meados da dcada de 90 havia mais de 1000 metodologias.As metodologias actualmente existentes tiveram essencialmente 2 origens distintas:- Evoluram de experincias prticas- Resultaram de esforos de investigao

2.3. Modelos e ModelaoUm modelo consiste na interpretao de um dado domnio do problema segundo umadeterminada estrutura de conceitos.Um esquema a especificao de um modelo usando uma determinada linguagem. quando grfica chamamo-lhe diagrama.Um modelo sempre uma interpretao simplificada da realidade.Um modelo apresenta apenas uma viso ou cenrio de um fragmento do mundo real --> vriosmodelos para compreender o sistema correspondente.

2.3.1. Importncia da ModelaoA modelao (ou modelizao) a arte e cincia de criar modelos de uma determinada realidade;facilita e promove a comunicao entre todos.A informtica como as outras engenharias precisa tambm de adoptar notaes e linguagens pararepresentar os seus modelos. Os benefcios da modelizao so:


6/35

- Ajudam a visualizar o sistema- Permitem especificar a estrutura ou o comportamento- Permitem controlar e guiar o processo de construo- Documentam as decises tomadas

2.3.2. Princpios da modelaoP1 A escolha dos modelos a criar tem uma profunda influncia no modo como o problema

encarado e consequentemente como a soluo obtidaP2 cada modelo deve poder ser expresso em diferentes nveis de preciso/abstracoP3 Os melhores modelos reflectem a realidadeEste princpio um dos calcanhares de Aquiles das tcnicas de modelao pois muitas vezesexiste uma manifesta separao entre os modelos usados para descrever o que o sistema faz eoutros que detalham a forma como o sistema faz.P4 Nenhum modelo suficiente por si s. Qualquer sistema no trivial representado de formamais adequada atravs de pequeno nmero de modelos, razoavelmente independentes (masmantendo nvel de integrao).O UML baseia-se significativamente neste princpio.

2.4. Boas Prticas no Desenvolvimento de SoftwareA complexidade do software uma propriedade essencial, intrnseca prpria natureza dosoftware e tem origem em 4 factores:- A complexidade do domnio do problema- A dificuldade de gerir o processo de desenvolvimento- A flexibilidade que possvel (ou no) implementar atravs do software- Os problemas de caracterizar o comportamento de sistemas discretosAssim, normalmente, os projectos ultrapassam custos e prazos.H vrios atributos de um sistema complexo:- composto por outros subsistemas relacionados, e assim sucessivamente (hierarquia deelementos)- A seleco dos componentes elementares arbitrria e depende de quem a efectua

- Com muitos elementos, as relaes intracomponentes so mais fortes do que asintercomponentes- Cada subsistema normalmente composto por poucos componentes diferentes- Um sistema complexo que funciona invariavelmente uma evoluo de um sistema simples quej funcionou.Existe uma limitao natural da capacidade humana em lidar com a complexidade. Por issoDijkstra sugeriu a aplicao do famoso princpio da decomposio hierrquica (divide andconquer)Tambm a aplicao de um mecanismo de abstraco favorece a eliminao da complexidade: oser humano opta por esquecer os detalhes menos importantes.Outros princpios para lidar com a complexidade e obter software de qualidade so:- Desenvolvimento de forma iterativa

- Efectuar gesto integrada dos requisitos- Utilizar arquitecturas baseadas em componentes reutilizveis- Modelar o sistema atravs de diagramas grficos- Efectuar a verificao sistemtica da qualidade- Implementar um processo sistemtico de controlo de alteraesCada uma destas melhores prticas tem impacto nas outras.Ainda h mais princpios:- Conseguir promover o envolvimento dos utilizadores- Utilizar abordagem orientada para a resoluo de problemas- Definir e utilizar standards para o desenvolvimento e documentao- Justificar o desenvolvimento do software com actividade estratgica e investimento financeiro- Conceber sistemas de modo a facilitar a sua expanso e alterao

2.5. fases do Desenvolvimento de Software


7/35

Necessidade de aplicar um processo com fases bem definidas, que se subdividem em conceitosmais elementares (tarefas e actividades), isto desde que se verificou que a programaoestruturada no era suficiente.A natureza sequencial obriga a que uma fase (ou tarefa ou actividade) tenha de estar terminadaantes de outra comear.Nesta perspectiva, uma fase constituda por uma sequncia de tarefas, e estas por sua vez soformadas por actividades. Os 2 primeiros so abstractos e as actividades correspondem de facto a

trabalho realizado, sendo pois a unidade mais elementar.-Um processo divide-se em trs grandes fases:- Concepo: identificar o que que o sistema deve fazer. Inclui Planeamento e Anlise- Implementao: identificar o como fazer o sistema. Inclui Desenho, Desenvolvimento, Testes eIntegrao e Instalao- Manuteno. Inclui Operao e ManutenoH quem considere que o levantamento dos requisitos do sistema e a respectiva especificaoso tarefas distintas, enquanto outros autores juntam ambas na tarefa de anlise e consideram-nacomo duas actividades da referida tarefa (nossa opo).H quem considere que o desenho uma tarefa da concepo uma vez que as actividades sode definio e no de implementao. A nossa viso que definio do que se vai fazer, logofica na implementao.As fases podem ser divididas em tarefas mais especficas:- Planeamento: identificao geral das necessidades e seleco de alternativas- Anlise: Identificao detalhada das funcionalidades (Levantamento de Requisitos) e respectivadescrio (Especificao do Sistema)- Desenho: Definio detalhada da arquitectura global (mdulos, tabelas, interface, mquinas,etc.)- Desenvolvimento: Programao- Testes (ou Integrao): O sistema no seu global verificado para obter aceitao do utilizador- Instalao: Disponibilizao dos sistema para os seus utilizadores finais- Manuteno: O momento que corresponde ao tempo de vida til do sistema e durante o qual soefectuadas todas as alteraes.

A manuteno sempre foi a tarefa que maior esforo e custos relativos apresenta. Mesmo com asmelhores tcnicas actuais continuamos quase na mesma (67%)

2.5.1. Tarefas Transversais- Gesto do ProjectoGesto dos recursos humanos, financeiros, controle de prazos. este o nvel que funciona comointerface oficial para fora da equipa de projecto --> gestor de projecto- Gesto de Alteraes fundamental que estejam previstos mecanismos de controle das alteraes

2.5.2. PlaneamentoAlguns autores no consideram no mbito da Engenharia de Software. Outros consideram-na

como transversal. A nossa perspectiva que s temos um projecto depois do seu plano estaraprovado, e esse o objectivo dessa tarefa.Existem vrias circunstncias particulares em que esta tarefa deve ser efectuada:- Num projecto que envolve a seleco de entidades para posterior implementao do software, aelaborao de cadernos de encargos e a avaliao de propostas- Apenas investigao inicialA grande preocupao desta fase que a partir de um levantamento de alto nvel dasnecessidades do negcio seja possvel elaborar um plano de projecto. Para isso existem umconjunto de actividades que devero ser realizadas:- Compreender a misso e organizao da empresa- Identificar e envolver todos os interessados e afectados pela introduo do sistema- Obter uma viso de alto nvel do funcionamento do sistema actual (caso exista)- Definir o mbito do sistema- Elaborao de uma descrio de alto nvel do problema- Identificar restries, problemas e riscos do projecto


8/35

- Identificar alternativas de implementao, avali-las e seleccionar- Apresentar resultados e recomendaes, com justificao tcnica funcional e financeira- Elaborar e obter aprovao de um plano de projecto- Definir o processo de controlo do projectoO principal output desta tarefa ser um plano de projecto, que dever reflectir sustentadamente aviso que se tem nesta fase.

2.5.3. AnliseEfectua o estudo detalhado do domnio do problema, e culmina na elaborao de um documentoonde os requisitos funcionais da soluo a implementar e outras questes relevantes (restries,mbito, fluxos de informao) so enumerados. Tem, normalmente dois grandes momentos ousub-tarefas (realizados em simultneo):- Levantamento de RequisitosUm requisito uma funcionalidade ou condio que o sistema dever possuir. Reunies,observaes, prottipos,...- Especificao do SistemaNo tarefa fcil. As interpretaes so subjectivas. O objectivo geral desta subtarefa expressarsem ambiguidades o que os sistema deve fazer e no como fazer o sistema.A Especificao de Requisitos um documento que deve ser visto como um contrato.

2.5.4. DesenhoPretende efectuar a definio do domnio da soluo, com base na anlise. Procede-se especificao formal ou informal das caractersticas que a implementao do sistema deverapresentar. Inclui arquitectura de computadores, tecnologias de bases de dados, etc., bem comoambiente e linguagem de programao a usar.Diz-se por vezes que a fase de especificao tcnica pois aqui se definem componentesaplicacionais, tecnolgicos e dados.Factores como o desempenho, a segurana e a operacionalidade, custos e prazos, devero secritrios para seleccionar alternativas. Planos de testes e de migrao devero ser previstos.

2.5.5. Implementao a concretizao do modelo do desenho.Os componentes aplicacionais so codificados e testados de forma isolada (testes unitrios).Actualmente assiste-se, no contexto dos sistemas de informao cliente/servidor, crescenteutilizao de ambientes de desenvolvimento bastante produtivos (designados por ambientes RAID Rapid Application Development), baseados em infra-estruturas de objectos/componentesevoludos, complexos e providenciando paradigmas de prototipagem de desenvolvimento visual(ex. ferramentas CASE).Cada vez mais as organizaes compram produtos previamente desenvolvidos mais ou menosuniformizados funcionalmente (pacotes), o que levou a que a programao pura cedeu uma parteda sua importncia em favor de esforos de integrao (entre os diverso componentes pr-fabricados), sua parametrizao e configurao.

2.5.6. TestesOs testes devero ser executados em condies idnticas aquelas que o sistema real ir possuir.Podem ser classificados em diferentes categorias, segundo as caractersticas do sistema queavaliam:- Testes de carga: avaliam o sistema perante a utilizao intensiva e aferem as capacidades deescalabilidade- Testes de desempenho: Analisam o tempo de resposta do sistema e verificam o nvel deutilizao dos recursos disponveis- Testes de usabilidade: analisam a adequabilidade do desenho das interfaces homem-mquina- Testes funcionais: se os requisitos so satisfeitosOutra classificao segundo o mbito dos componentes do sistema:- Testes unitrios- Testes de integrao- Testes de sistema


9/35

- Testes de aceitaoNo caso de substituio de sistemas muitas vezes usa-se a estratgia do paralelo de sistemas(repetio das actividades do antigo sistema, no novo).A verificao deve ser acompanhada a diferentes nveis por ferramentas de debugging.

2.5.7. InstalaoEnvolve um conjunto de tarefas:

- Configurao e parametrizao do sistema- Instalao dos componentes aplicacionais necessrios- Definio de perfis, de utilizadores e de nveis de segurana- Formao dos utilizadores do sistema- Elaborao de documentao de operao, administrao e utilizao do sistema- Definio e implementao de polticas de segurana (ex. backups)

2.5.8. ManutenoCom o tempo aparecem os bugs, para alm de solicitaes externas e internas relativamente apedidos de alterao de requisitos.Novos requisitos (60%); Erros (18%); Melhorias (18%). possvel ver a tarefa de manuteno desencadeia uma nova iterao de todo o processo.

2.6. Processos de Desenvolvimento de SoftwarePodemos distinguir genericamente duas grandes aproximaes:- modelo em cascata- aproximao iterativa

2.6.1. Processos em CascataSo os mais tradicionais, em que as actividades a executar so agrupadas em tarefas,executadas sequencialmente, de forma a que uma tarefa s tem incio quando a tarefa anteriortiver terminado.Baseia-se no pressuposto que o cliente participa activamente (e vai validando as vrias tarefas)

no projecto e que sabe muito bem o que quer. Mas, infelizmente, a salvaguarda no evita que ocliente fique desapontado.O modelo apresenta ainda outras limitaes, como a compartimentao de esforos, odesencorajamento de comunicao, no se pode voltar atrs mesmo que as conclusesanteriores sejam modificadas com o evoluir do processo.De forma a evitar este problema foi criado o modelo em cascata revisto (ciclo).O risco desta abordagem que, na ausncia de um processo de gesto e controle bem definido,podemos passar o tempo num ciclo sem fim.Ambos os modelos anteriores apresentam o problema da extenso do perodo de tempo quedecorre entre o incio do projecto e a entrega do produto.Uma soluo consiste na aplicao de tcnicas de prototipagem logo no incio do processo(prototipagem rpida). No elimina a necessidade de todas as tarefas sequenciais, mas permite

que o cliente veja e valide um modelo da interface (e das funcionalidades) que ir ter disponvel,reduzindo tambm os problemas de comunicao. Aqui preciso cuidado e saber resistir presso do cliente que quer passar a utilizar de imediato o prottipo. Alm de se poder perder aviso global face ao imediatismo dos crans.

2.6.2. Processos Iterativos e IncrementaisSo mais recentes e pretendem encorajar a comunicao.IterativoCorresponde ideia de melhorar (ou refinar) pouco-a-pouco (ex. trabalho artstico).Vantagens:- Os riscos e as dvidas com maior importncia so identificados no incio do processo, nasprimeiras iteraes, quando possvel tomar medidas para os corrigir.- Encoraja a participao activa dos utilizadores- Testes contnuos e iterativos permitem avaliao contnua do estado do projecto- As inconsistncias entre desenho e implementao so detectadas atempadamente


10/35

- O esforo dos elementos distribudo ao longo do tempo- A equipa pode aprender com experincias anterioresIncrementalCorresponde ideia de aumentar (ou alargar) pouco-a-pouco o mbito do sistema. ex. manso apartir de 2 anexos.Iterativo e IncrementalA principal consequncia que os produtos finais de todo o processo vo sendo amadurecidos e

completados ao longo do tempo.Espiral uma pequena variante do modelo iterativo e incremental. Prope logo de seguida tarefa deplaneamento a realizao de uma tarefa de prototipagem e de anlise de risco.


11/35

CAP. 3 EVOLUO DAS METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE3.1. IntroduoLarry Constantine tentou identificar mecanismos que possibilitassem que a concepo inadequadade software fosse evitada desde o incio, aquando da identificao dos requisitos. Em conjuntocom Wayne Stevens e Glen Myers props o conceito de Composite Design, renomeado paradesenho estruturado [Stevens74].

3.2. A Programao Como Fonte de InovaoDepois do programa, veio o mdulo.A ideia era agrupar num mdulo dados e cdigo, que estivessem relacionados de forma a limitaras interaces entre mdulos invocao de funes. No entanto era ainda possvel aceder doexterior aos dados declarados dentro de um mdulo.Para evitar isso foi proposto o conceito de tipo de dados abstracto (ADA) que permitem escondertotalmente partes da sua implementao (quer o nvel de dados quer cdigo), e disponibilizampara o exterior o que se designa por interface. Ligao muito forte entre dados e cdigo.A evoluo levou ao aparecimento das linguagens orientadas por objectos (Smalltalk, C++, Java,Object Pascal).A principal diferena para os tipos de dados abstracto que as OO suportam a noo de herana

3.3. O Desenvolvimento Ad-HocEm face das potencialidades limitadas das LP, as primeiras aplicaes foram construdas sem autilizao de uma metodologia de desenvolvimento formal, correspondendo ao que normalmentese designa por programar e corrigir (build and fix).Estes desenvolvimentos eram caracterizados por:- Envolvimento limitado dos utilizadores- Identificao de requisitos efectuada de forma inadequada- Fraca utilizao de tcnicas de anlise e desenho- Inexistncia de ferramentas de apoio a todo o processo- tarefas de desenvolvimento muito demoradas- Sistemas de acesso informao pouco flexveis

Quando a complexidade aumentou, a situao ficou mais problemtica, o que ainda foi agravadopor:- Os informticos eram reconhecidamente bons programadores, mas raramente tinhampreocupao de compreender o negcio- No eram aplicadas tcnicas ou mecanismos de controlo e de gesto do projecto, e por issoestes ultrapassavam frequentemente custos e prazos estimados- A fraca qualidade do produto final implicava correces frequentes

3.4. Metodologias EstruturadasDurante os anos 70 e 80 assistiu-se introduo de tcnicas estruturadas de decomposiofuncional, com o objectivo de identificar os requisitos e introduzir tcnicas baseadas nas melhoresprticas ao processo de anlise e desenho.

3.4.1. Contexto e MotivaoO objectivo era prestar mais ateno ao processo global e menos programao. A maioria dasmetodologias adoptaram o modelo em cascata.As metodologias estruturadas estavam orientadas segundo uma de 2 abordagens:- Mais orientada para a decomposio funcional do sistema e identificao dos respectivosprocessos (funcional) funes, algoritmos e actividades- Mais centrada nos conceitos e nos dados das organizaes (orgnica)

Na anlise funcional o suporte dado pelas LP da altura permitiam diviso do cdigo em blocos e,assim, um certo encapsulamento. No entanto, a possibilidade dos dados serem globalmentevisveis e manipulados por todo o programa reduzia estas caractersticas e era pouco flexvel aalteraes.Na anlise orgnica a ateno concentra-se nos dados, colocando os conceitos e as entidadesmanipuladas no negcio como elementos chave. A ideia mesmo quando uma aplicao muda,os conceitos principais devem permanecer e continuar a ser utilizados.


12/35


13/35

- Linguagem Z: Com conceitos matemticos e lgicos de 1 ordem (conjuntos, tipos de dados,constantes, definies de estado, estado inicial, operes)

3.4.4. Principais MetodologiasSSADM (Structured Sistems Analysis and Design Methodology). Proposta em 1981 por Learmoth.Prope a modelao de um sistema segundo 3 perspectivas complementares:- a sua funcionalidade (diagrama de fluxo de dados)

- a sua estrutura (diagrama de entidade associao)- a sua evoluo ao longo do tempo (diagramas de ciclo de vida) concebida para a anlise e desenho no contemplando a implementao, testes e instalao.A sequncia de actividades envolve:- A realizao de um estudo de viabilidade- A anlise de requisitos do negcio- A especificao dos mesmos requisitos- A especificao lgica do sistema- O desenho fsico do sistema

Stradis (Strutured analysis, design and implementation of information systems). Gane e Sarsonnos finais da dcada de 70, baseada na filosofia de decomposio funcional top-down e suportadaessencialmente pela utilizao de diagramas de fluxo de dados.

Yourdon Systems Method1993, Edward Yourdon. semelhante Stradis pois recorre muito decomposio funcional mastambm atribui importncia significativa s estruturas de dados.

Engenharia de InformaoJames Martin em 1989. Integra muitos conceitos das outras.Ao contrrio das outras tem uma preocupao estratgica com a definio dos sistemas deinformao, o que expresso nos diferentes estgios de evoluo do processo: planeamentoestratgico; anlise de reas de negcio; desenho de sistemas; implementao.

3.5. Metodologias Orientadas por ObjectosAs tcnicas anteriores apresentavam vrios problemas:- No conseguem lidar adequadamente com o problema da complexidade e do tamanhocrescente dos sistemas- No resolvem o problema da crescente actividade de manuteno do software- Verifica-se com frequncia a m compreenso dos requisitos do utilizador por parte dos tcnicos- Permanece a dificuldade de lidar com alteraes aos requisitos- A integrao e reutilizao de mdulos e componentes no so fceis- Os erros de concepo so descobertos tardiamente- A qualidade do software baixa e o seu desempenho inadequado- No fcil identificar quem fez o qu, quando e porqu.

O conceito de orientao por objectos baseia-se de facto numa nova forma de analisar o mundo.A abordagem seguida reproduz a forma como o ser humano se apercebe e expressa a realidadeque o rodeia. Ele classifica e subdivide o mundo em diferentes objectos, com base nas diferenase semelhanas existentes ao nvel das caractersticas e comportamentos. Isso permite areutilizao dos objectos.A perspectiva de modelao muda, uma vez que o mesmo conceito base utilizado ao longo detodas as fases do processo, promovendo a reutilizao e o encapsulamento da informao,facilitando a manuteno.

3.5.1. Contexto e MotivaoSimula nos finais dos 60; Smalltalk nos 70.Motivaes principais para a realizao de actividades de anlise segundo o OO:- Poder tratar domnios de problemas mais complexos- Melhorar a interaco entre o analista e o especialista do problema- Aumentar a consistncia interna dos resultados da anlise


14/35


15/35

Por ex. ver [Coad91] e checklists para saber quando um objecto potencial no o , na pg.93.ex. funcionrio; requisio; bens; armazm.As operaes realizadas por objectos podem ser identificadas pela pesquisa no enunciado doproblema de verbos associados a cada objecto. Essas operaes podem ser agrupadas em:- Modificadores: operao que altera o estado do objecto.- Selectores: Operao que acede ao estado de um objecto- Iteradores: operao que permite que todas as partes de um objecto sejam acedidas segundo

uma ordem bem definida- Destrutor: Liberta o estado de um objecto ou elimina-o.Uma mensagem sempre formada por um selector e opcionalmente por um conjunto deparmetros.A interface o conjunto de operaes e atributos disponibilizados por uma classe, que consoantea visibilidade pode ser pblica (visvel por todos os objectos do sistema), privada 8s visvel pelaprpria classe) ou protegida (pela classe e subclasses).Entre as diversas classes podem ser estabelecidas diferentes tipos de relaes:- Associao: Representam as relaes estruturais entre objectos de classes diferentes (ter).Subdivide-se em:

- Agregao: Relao entre o todo e as partes (uma empresa tem empregados)- Composio: O corpo humano tem uma perna- Dependncia: Relao em que uma mudana de estado num objecto (ocorrida pela

recepo de uma mensagem) pode implicar o envio de uma mensagem a outro objecto.- Generalizao/Especializao: Relaes entre classes que partilham a estrutura ecomportamento; implementam o conceito de herana (ser). Um co um animal.Subsistema um conjunto de classes (ou outros subsistemas) que colaboram entre si pararealizar um conjunto de responsabilidades (no UML o pacote).

3.5.3. Tcnicas e Notaes Mais UtilizadasVer UML mais frente.

3.5.4. Principais Metodologias

Ao longo das dcadas de 80 e 90_- Mtodo de Booch (1991): baseia-se na ideia da repetio de actividades de um processo dedesenvolvimento de modo a refinar o modelo em sucessivas iteraes. As suas principaisactividades esto orientadas para a identificao de classes e objectos e respectivascaractersticas e para a determinao das relaes entre classes.- OMT (Object Modelling Technique)- James Rumbaugh (1991): concentrou-se na anlise edesenho de software.3 modelos essenciais:

- esttico ou de objectos (rep. classes, objectos, relaes)- dinmico (comportamento dos objectos e sistema global)- funcional (diagrama de fluxo de informao)

- OOSE (Object Oriented Software Engineering) Ivar Jacobson (1992)

Resulta da evoluo do modelo Objectory e a sua maior contribuio foi a introduo da noo decaso de utilizao.- OOAD (Object Oriented Analysis and Design) Peter Code e Edward Yourdon (1991)vantagem: simplicidade (de conceitos, actividades e diagramas)

- Identificar objectos utilizando critrios simples (substantivos)- Definir uma estrutura de relaes generalizao-especilaizao- Definir uma estrutura de relaes de associao (whole-part)- Identificar assuntos (subsistemas)- Definir os atributos- Definir os servios

- Mtodo de Wirfs-BrockNo efectua distino clara entre anlise e desenho e a sua principal contribuio foi a definiode diagrama designado por CRC cards (Class-Responsibility-Colaboration) que procura identificaras classes dos sistema, a sua interface e as relaes entre elas.- Rational (cap.10)


16/35

3.6. Outras MetodologiasAs metodologias no esto isentas de crticas e aspectos menos positivos:- Complexidade nos conceitos, tcnicas e aplicao- Desconhecimento global e falta de competncias dos informticos para a sua execuo comqualidade- Ferramentas difceis de utilizar

- Constatao da ausncia de melhorias no processo e produto final- Concentrao na anlise da situao actual e no no futuro- Tempo- RigidezComo reaco apareceram um conjunto de metodologias que usam um formalismo muito menor.Cdigo fonte tudo em documentao e as principais actividades so programar e testar.Concentram-se na satisfao das necessidades das pessoas e no na definio dos processos. iterativo.No h designao formal para elas ainda mas usa-se o termo lightweight.XP Extreme Programming e DSDM Dynamic System Development Method.So aconselhveis para sistemas pequenos e com requisitos incertos ou volteis e com tcnicos eutilizadores motivados.

3.7. Comparao de Metodologias tarefa complexa devido a:- No existem metodologias iguais- Muitas metodologias so influenciadas ou concebidas para linguagens de programaoespecficas- Muitas metodologias assumem contexto particular de aplicao- A abrangncia varia fortementeHoje em dia reconhecem-se vantagens das OO relativamente s estruturadas, porqueapresentam:- Um nico paradigma consistente ao longo de todo o processo, mais prximo do processo de

cognio humano- Facilitam a reutilizao- Modelos que reflectem o mundo real- No existe separao entre dados e processos- Os detalhes de implementao esto escondidos (encapsulamento)- Maior facilidade de tarefas de manuteno- O sistema mais estvels vezes o problema encontrar objectos e classes apropriados pois os informticos continuam apensar funcionalmente.

3.7.1. Gesto de Requisitos e Facilidade de ManutenoNo desenvolvimento estruturado, o sistema consiste num conjunto de dados que so usados

(leitura ou escrita) por inmeras funes. pois uma malha arbitrria de inmerasinterdependncias entre funes e dados.No OO, dados e funes so agregados conjuntamente numa entidade lgica (o objecto) queprovidencia uma interface bem definida para outros objectos comunicarem com ele. O sistemacorresponde a uma malha de interdependncias entre objectos. evidente que as OO facilitam a gesto de alteraes de requisitos. Ex alterao da estrutura dedados implicava alterar todas as funes; no OO desde que interface no mudasse era fcil.

3.7.2. Representao da RealidadeNas abordagens OO, as entidades do mundo real so captadas directamente por objectos. Nasestruturadas o foco no desenho da base de dados ou, alternativamente, na definio dosprocessos/funes que acedem e manipulam essas bases. Difcil especializar contas bancrias.

3.7.3. Outros AspectosOutras vantagens:


17/35

- Providencia blocos de construo de alto nvel que reduzem os custos de desenvolvimento, pelapromoo da reutilizao e encapsulamento de software. Este facto permite reduzir asinterdependncias e facilita manuteno posterior.- Facilita transferncia de conhecimento atravs da adopo de padres de desenho, reduzindocustos de aprendizagem- Providencia framework (aplicacional ou de middleware) para facilitar a extenso do sistema,reduzindo o custo de novas verses

- Reduz o custo de alterao do sistema.Todavia h que ter alguns cuidados na sua aplicao:- Exige uma nova forma de pensar o processo de desenvolvimento- Deve ser usada em todas as fases do ciclo de vida do software- A gesto da empresa tem de comprar a mudana para a filosofia OO (ex. reduo de custos demanuteno)- A migrao deve ser devidamente planeada.


18/35

Parte 2 Linguagem de Modelao UMLO UMLO UML (Unified Modelling Language) uma linguagem diagramtica, utilizvel para especificao,visualizao e documentao de sistemas de software.Tem as seguintes caractersticas principais:- independente do domnio de aplicao (sistemas cliente/servidor tradicionais, sistemas

baseados na web, de informao geogrficos, de tempo real, etc.).- independente do processo ou metodologia- independente das ferramentas de modelao- Apresenta mecanismos potentes de extenso- Agrega um conjunto muito significativo de diferentes diagramas/tcnicas dispersos por diferenteslinguagens (diagramas de casos de utilizao, de classes, de objectos, de colaborao, deactividades, de estados, de componentes, e de instalao).O objectivo principal do UML promover e facilitar a comunicao entre um grupo variado deintervenientes.

CAP. 4 UML VISO GERAL4.1. IntroduoO UML uma linguagem para especificao, construo, visualizao e documentao deartefactos de um sistema de software.O UML providencia as seguintes particularidades principais- Semntica e notao para tratar um grande nmero de tpicos actuais de modelao- Semntica para tratar tpicos de modelao futura (tecnologia de componentes, computaodistribuda, frameworks e Internet)- Mecanismos de extenso- Semntica e sintaxe para facilitar a troca de modelos entre ferramentas distintas independente das linguagens de programao, das ferramentas CASE e dos processos dedesenvolvimento.Os novos elementos introduzidos no UML so:

- Mecanismos de extenso- Elementos para modelar processos e threads- Elementos para modelar concorrncia e distribuio- Padres de desenho e colaboraes- Diagramas de actividades (para modelao de processos de negcio)- Refinamento- Interfaces e componentes- Linguagem de restries (OCL)O UML providencia os seguintes tipos de diagramas:- De casos de utilizao- De classes e de objectos- De comportamento

- De estados (statechart)- De actividades- De interaco ( de sequncia e de colaborao)

- De arquitectura- De componentes- De instalao

4.2. Viso Histricafase da fragmentao fase da unificao fase da standardizao fase da industrializao.Actualmente assiste-se divulgao e adopo generalizada do UML como a linguagem demodelao de software segundo a abordagem orientada por objectos.H 2 aspectos importantes que se obtm com o UML:- Terminam as diferenas, geralmente inconsequentes, entre as linguagens de modelao dosanteriores mtodos


19/35


20/35


21/35

- Localizao: perto dos elementos que descrevem- Visibilidade: escondidas ou visveis- Extenso: usar referncias (URLs, etc.)- Evoluo

4.6.2. Mecanismos de ExtensoSo os Esteretipos; Marcas e Restries.

No seu uso deve-se:- Introduzir um nmero reduzido- Escolher nomes curtos e com significado, para os 2 primeiros- Usar texto livre para especificao das restries, sempre que a preciso possa ser relaxada.- Deve ser realizada por especialistas em UML, principalmente no caso dos esteretipos

Esteretipos um metatipo. Permite definir novos tipos de elementos sem se alterar o metamodelo do UML A definio de um esteretipo tem de ter em conta os seguintes aspectos:- Propriedades (pode providenciar o seu prprio conjunto de marcas)- Semntica (pode providenciar as suas prprias restries)- Notao (pode providenciar o seu prprio cone)- A classe base do metamodelo, que vai ser estendida

Marcas Com ValorCada elemento em UML tem um conjunto de propriedades. Por exemplo: as classes tm umnome, uma lista de atributos e uma lista de operaes; as associaes tm um nome e dois oumais elementos participantes. Enquanto que os esteretipos permitem adicionar novoselementos UML, as marcas com valor permitem adicionar novas propriedades aos elementos.Deve ser entendida como metadata (isto dados que descrevem dados) pois o seu valor aplica-se ao prprio elemento e no s suas instncias. { }

Restries (constraints)

Permitem adicionar ou alterar a semntica assumida por omisso de qualquer elemento UML.{ } A condio pode ser especificada numa linguagem formal ou informal.

4.7. Tipos de Dados uma abstraco utilizada de forma implcita no UML. No so elementos do modelo e porconseguinte no lhe so associados esteretipos, marcas com valor ou restries. Um tipoprimitivo no tem subestrutura.- Primitivos: Integer, String, Time- Enumerados: Boolean, AggregationKind, VisibilityKind- Outros: Expression, Mapping, Name, Multiplicity

4.8. Organizao dos Artefactos pacotes

Um pacote (package) em UML um elemento meramente organizacional. Permite agregardiferentes elementos de um sistema em grupos de forma que semntica ou estruturalmente faasentido.A necessidade evidente em sistemas de mdia/grande dimenso, impossveis de modelar deuma s vez. Os benefcios so:- Facilita a gesto e procura de artefactos- Evita conflito de nomes ( X::A diferente de X::Y::A, e diferente de Z::A )- Providencia um mecanismo de controlo de acessos (visibilidade)

4.8.1. Representao GrficaOs pacotes so representados por uma pasta (tabbed folder) com duas zonas complementares:um pequeno rectngulo (designado por tabulador ou tab), normalmente com o nome do pacote; eum rectngulo maior onde normalmente se especificam os elementos constituintes. H vriasformas alternativas e o + significa visibilidade (dos elementos) pblica, - privada e # protegida.Pode-se ainda especificar hierarquias e marcas, esteretipos e restries.


22/35

4.8.2. Relaes Entre PacotesImportao; Exportao e Generalizao.Visibilidade- pblica: o elemento pode ser usado/referenciado por qualquer outro elementoindependentemente do local onde definido- privada: pode ser usado/referenciado por elementos definidos no mesmo pacote- protegida: pode ser usado/referenciado por um elemento definido no mesmo pacote ou num

outro pacote que seja uma especializao (atravs da relao de herana) do primeiro.Tambm se pode definir relao de friend entre 2 pacotes ( uma relao de dependncia entrepacotes, com esteretipo friend). Contudo esta relao deve ser evitada porque viola osprincpios do encapsulamento e da minimizao de dependncias.

Importao e ExportaoUm pacote faz a exportao, por definio, de todos os seus elementos pblicos. mas tal factono implica que um elemento definido noutro pacote possa aceder/referenciar um elementoexportado num outro pacote. Para que tal acontecesse deveria existir explicitamente uma relaode importao entre esses dois pacotes.A relao de importao uma relao de dependncia entre pacotes, especificando que opacote base importa todos os elementos pblicos definidos no pacote destino. representada poruma linha dirigida, a tracejado, com esteretipo import. No transitiva. No simtrica.Preferencialmente, os elementos exportados por cada pacote devem ser do tipo interface.

Generalizao semelhante homloga existente entre classes, e usada para especificao de famlias depacotes, tpicas em sistemas complexos ou flexveis (significativamente parametrizveis, multi-plataforma, multi-linguagem). Permite especializar pacotes.

4.8.3. Tipos de PacotesAo contrrio dos exerccios acadmicos, em situaes reais de modelao de sistemas desoftware de mdia/grande dimenso, realizadas por equipas, torna-se necessrio tipificar os

prprios pacotes. A especificao UML prope 5 esteretipos standard:- system : pacote que representa o sistema inteiro. Agrega os outros.- subsystem : representa uma parte do sistema- facade : pacote com elementos (tipicamente classes e interfaces) que constituem a fachada(ou a interface de programao)- framework : uma arquitectura de classes e interfaces com inmeros pontos de variabilidadeou de extenso e com estruturas de objectos padronizadas, conhecidas por padres de desenho.O desenvolvimento de sistemas baseados em frameworks e em componentes de software umtpico emergente extremamente actual.- stub: um adaptador (stub) usado quando se pretende partir um sistema em diferentespacotes por motivos de diviso de trabalho.Em geral os pacotes mais usados so sistema ou subsistema.

4.8.4. Modelao de Grupos de ElementosAlgumas formas clssicas de organizao dos artefactos de projectos em termos de pacotes:- Organizao por casos de utilizao: ex. ICONIX- Organizao por tipos de modelos: ex. RUP


23/35

CAP. 5 UML CASOS DE UTILIZAO5.1. IntroduoA engenharia de requisitos preocupa-se em capturar, armazenar e gerir requisitos.Um requisito uma especificao de uma determinada aco ou condio que o sistema devesatisfazer.Um requisito funcional descreve uma dada aco (ou funo) que o sistema deve suportar.Um requisito no funcional descreve um aspecto (no funcional) que o sistema deve satisfazer.

Requisitos no funcionais tm a ver com aspectos gerais do sistema, tais como: desempenho,robustez, fiabilidade, distribuio, segurana, integrao com Internet, abertura, ou suporte destandards.O UML inclui os diagramas de casos de utilizao (use cases) que permitem a especificao derequisitos funcionais segundo uma aproximao focada principalmente nos utilizadores dosistema. Esta abordagem facilita a comunicao.A relao entre casos de utilizao e requisitos no pacfica.H alguns aspectos importantes na especificao de requisitos, que tm a ver com a suaapresentao, organizao e nvel de detalhe.Quanto aos 2 primeiros h autores que advogam diagramas (de casos de utilizao)seguidamente cada caso em particular deve ser especificado em detalhe atravs de descriotextual e, opcionalmente, atravs de um ou mais diagramas de colaborao e/ou desenhos deprottipos de interfaces homem-mquina (ex. screenshots).Quando os requisitos so descritos textualmente, recomenda-se normalmente que sejamnumerados sequencialmente segundo, pelo menos, duas sequncias distintas: uma para osrequisitos funcionais e outra para os requisitos no funcionais. Por outro lado, quando osrequisitos so baseados nos casos de utilizao, deve usar-se o elemento pacote do UML comoelemento estruturante.Em geral prefervel a descrio de casos de utilizao de forma no muito detalhada, variandoentre uma a 5 pginas.

5.2. Casos de Utilizao uma sequncia de aces que um ou mais actores realizam num sistema de modo a obterem

um resultado particular.O modelo de casos de utilizao permite capturar os requisitos de um sistema atravs de umdetalhe de todos os cenrios que os utilizadores podem realizar. mais que iniciar a modelao derequisitos do sistema, os casos de utilizao dirigem/conduzem todo o processo dedesenvolvimento. representado por uma oval, com uma frase (verbo no infinitivo) que representa uma aco.Deve descrever o que faz o sistema mas no como o faz. pois a viso do utilizador.

5.2.1. Casos de Utilizao e CenriosUm cenrio (2fluxo de aces) uma determinada sequncia de aces que ilustra umcomportamento do sistema; uma instncia de um caso de utilizao.Deve-se especificar o comportamento de um caso de utilizao descrevendo textualmente um

mais fluxos de situao em linguagem no-tcnica. deve incluir:- Como e quando o caso de utilizao comea e termina- Quando que o caso de utilizao interactua com os actores- que objectos so trocados- Cenrio principal, e- Cenrios alternativos (situaes de excepo)ex. 5.1 Especificao textual do caso de utilizao Validar Utilizador:Nome; Cenrio Principal; Cenrio Alternativo 1 (Cliente cancela operao); cenrio alternativo 2(PIN Invlido).Um aspecto importante o nvel de detalhe, que varia muito consoante o tipo de projecto.Normalmente textual e pode ser complementada por diagramas de interaco ou at prottiposde interfaces.Deve evitar-se linguagem tcnica, aspectos tecnolgicos, referir explicitamente pessoas (simpapis) , departamentos especficos, componentes de interface (botes, menus, etc.) oureferncias a dispositivos de hardware.


24/35

5.2.2. Relaes entre Casos de UtilizaoGeneralizao; Incluso e Extenso.Potenciam significativamente a reutilizao de especificao de requisitos.GeneralizaoPermite definir casos custa de outros j existentes, pelo mecanismo de especializao, oualternativamente, permite definir casos mais abstractos a partir de casos concretos pelomecanismo da reduo ou generalizao.

Incluso (include)Corresponde a uma relao tpica de delegao, isto , o caso base incorpora o comportamentodo outro caso relacionado. Usa-se para evitar a descrio dos mesmos fluxos inmeras vezes.Ex: Obter Extracto de conta e Realizar Pagamentos include Validar Utilizador.A questo importante como indicar, em que ponto da especificao, o caso de utilizaorelacionado deve ser incorporado no caso base. Este um aspecto essencial na compreenso edomnio dos casos de utilizao. Deve ser efectuada na especificao textual do caso deutilizao.Ex. 5.2. Especificao textual do caso de utilizao Obter Extracto de ContaNome; Cenrio Principal; Incluir caso de utilizao Validar Utilizador;...

Extenso (extend)O caso base incorpora implicitamente o seu comportamento num local especificadoindirectamente pelo caso que usado. Ou seja, o caso destino pode ser estendido com ocomportamento de outro(s) caso(s). Permite representar:- A parte de um caso que um utilizador v como opcional, ou como existindo vrias alternativas- Um subfluxo de aces que executado apenas se determinadas condies se verificarem- Vrios fluxos de aces que podem ser inseridos num determinado ponto de extenso, de formacontrolada, atravs de uma interaco explcita com um actor.O caso de utilizao de destino estendido num ou mais pontos (pontos de extenso), ou sejaso pontos de entrada do caso de utilizao que lhe d algum nvel de configurabilidade eversatilidade.Ex. escolher n de dias no Obter Extracto de Conta.

Textual: Nome: Obter Extracto de Conta; Pontos de Extenso: N de Dias; Cenrio Principal;Cenrio Alternativo 1.

5.3. Diagramas de Casos de UtilizaoIlustra um conjunto de casos de utilizao, de actores e suas relaes. As aplicaes maiscomuns so:- Para modelar o contexto de um sistema- Para modelar os requisitos de um sistemaA ligao entre um actor e um caso de utilizao corresponde a um esteretipo de comunicao(communicate). representada por linha a cheio.

5.3.1. Actores

o conceito que representa, em geral mas nem sempre (ex. outro sistema informtico, hardware,ou tempo), um papel que um utilizador desempenha relativamente ao sistema em anlise.

5.3.2. Casos de Utilizao Abstractos e ConcretosAbstracto: um caso que no apresenta uma relao de comunicao com qualquer actor ( o seunome representado a itlico).So tipicamente casos envolvidos em relaes de generalizao, incluso ou extenso comoutros casos de utilizao. O objectivo dar ao modelo um nvel elevado de reutilizao e deflexibilidade.

5.4. Proposta de Metodologia (parece fcil mas no )1) Identificar os actores do sistema2) Identificar, para cada actor, os seus casos de utilizao principais3) Com base nos casos de utilizao originai, identificar, factorizar e colocar em evidncia casosde utilizao que sejam recorrentes em mais que um dos casos originais. Nessa situao, cria-se


25/35

o novo caso (em geral abstracto) e os originais envolvidos estabelecem uma relao de inclusocom o dito caso. Repetir o processo at no se conseguir identificar qualquer outro caso areutilizar.4) Para flexibilidade e versatilidade, definir pontos de extenso (ou de variabilidade) econjuntamente definir um ou mais casos abstractos que os permitam estender nesses pontos.5) Especificar textualmente cada caso segundo um determinado formato previamente definido.ex: Mquina de bebidas

1) Cliente; agente do fornecedor; dono da mquina.2) Comprar bebida; Repor bebidas; Retirar dinheiro3) Repor bebidas e Retirar dinheiro envolvem Abrir Mquina e Fechar Mquina (incluso)4) Repor bebidas tem um ponto de extenso: encher prateleira (abstracto vrios algoritmos ex.de acordo com vendas)


26/35

CAP. 6 UML MODELAO DA ESTRUTURA6.1. IntroduoConsiste na identificao de classes e suas respectivas relaes.Uma classe consiste num estrutura que permite criar objectos semelhantes (em estado ecomportamento).O UML providencia os seguintes elementos que permitem a especificao da estrutura ou estticade um sistema de software:

- Classes- Relaes- Interfaces- Objectos.Com base nestes elementos podem fazer-se 2 tipos de diagramas com fins complementares:- Diagramas de Classes- Diagramas de Objectos

6.2. Classes a descrio de um conjunto de objectos que partilham os mesmos atributos, operaes,relaes e a mesma semntica. Corresponde a algo tangvel ou a uma abstraco conceptual. representada por um rectngulo, com uma, duas ou trs seces.Na 1 - nome da classe; na 2 - lista de atributos; 3 - lista de mtodos.Opcionalmente pode ter 4 - outra informao (ex. lista de responsabilidades que a classeassume)O nome pode vir na forma simples ou completa ( pacote::nome).Os atributos podem ter apenas o nome ou, adicionalmente, os respectivos tipos, visibilidade eoutras qualificaes.visibility name [multiplicity] : type-expression = initial-value {property-string}A multiplicidade por omisso 1..1 (exactamente 1).Nas operaes (mtodos) podem ver-se s os nomes ou tambm as assinaturas, visibilidade,outras qualificaes (ex. abstracta ou polimrfica).visibility name (parameter-list) : return-type-expression {property-string}

Podem definir-se subseces dentro da 2 ou 3 seces de forma a organizar melhor, com basena noo de esteretipo.

6.3. RelaesEstabelece a ligao entre elementos e representada graficamente por um determinado tipo delinha. Os 3 tipos de relaes mais importantes so:- Dependncias- Generalizaes- Associaes

6.3.1. Relao de DependnciaIndica que a alterao na especificao de um elemento pode afectar outro elemento que a usa,

mas no necessariamente o oposto. Linha dirigida a tracejado.No contexto de classes, usam-se dependncias para ilustrar que uma classe usa outra comoargumento na assinatura de uma das suas operaes ou como tipo na definio dos seusatributos. Por clareza no se usa normalmente nos diagramas, pois implcito. Usa-se mais compacotes e notas.

6.3.2. Relao de Generalizao uma relao entre um elemento geral (superclasse,...) e um elemento mais especfico. is-a ouis-a-kind-of. Representa-se por linha dirigida a cheio com um tringulo a branco num extremo.No contexto das classes usam-se para ilustra relaes de herana.A herana providencia mecanismo natural e potente de organizao dos programas de software,ao permitir:- Que cada subclasse herde o estado e comportamento de uma superclasse- Subclasses pode adicionar o seu prprio estado e comportamento- As subclasses podem ainda alterar os mtodos herdados, providenciando especializaes


27/35

Os benefcios da herana tm a ver com:- Possibilidade de reutilizao de cdigo- Definio de frameworks (programas com estruturas quase completas) atravs de classesabstractas que definem comportamentos genricos e/ou estilos de desenho comuns.Por omisso uma relao de generalizao representa uma decomposio disjunta ou exclusiva.No entanto outras semnticas podem ocorrer se especificadas:- Generalizao disjunta (disjoint): especifica que uma classe descendente de X pode apenas ser

descendente de uma das subclasses de X- Sobreposta (overlapping) Uma classe descendente de X pertence ao produto cartesiano dassubclasses de X- Completa (complete): completamente especificada ou no. ex. com e sem etiqueta.

6.3.3. Relao de AssociaoEspecifica que objectos de uma classe esto ligados a objectos de outra. ex. posse entreutilizador e password. representada por linha a cheio complementada por um conjunto de adornos quecomplementam a informao:- O nome- O papel de cada participante- A multiplicidade- O tipo de agregaoPodem ainda incluir os menos comuns navegao, visibilidade e qualificao

MultiplicidadeTraduz o n de instncias de uma classe que se podem relacionar com uma nica instncia daoutra.muitos (*); um ou mais (1..*), exactamente 1 (1), zero ou um (0..1), determinado n (3),determinada gama (2..6) ou listas (0..3,5..7,10..*)

Navegao

Traduz a forma como a partir de uma instncia de uma classe se pode aceder a uma ou maisinstncias de outra classe relacionada pela associao. Por omisso bidireccional. Mas podeinteressar ser unidireccional (ex: utilizador e password).

Agregao (Simples)Traduz que existe uma relao do tipo is-part-of ou has-a, isto , uma instncia de uma dadaclasse possuir ou ser composta por vrias instncias de outra classe. O adorno um losangojunto do elemento agregador ou o todo. Ex: PC e CPU, teclado, ...

Composio (Agregao Composta) uma variante da anterior, em que adicionada a seguinte semntica:(1) forte pertena do todo em relao parte

(2) tempo de vida delimitado (as partes no podem existir sem o todo)O adorno um losango a cheio. Ex. Empresa e Departamentos

Associaes QualificadasUm qualificador um atributo (da associao), ou lista de atributos, cujos valores servem parapartir o conjunto de instncias associadas a uma instncia ao longo de uma associao. representado por pequeno rectngulo junto do extremo de uma associao. colocado noextremo da classe origem da associao.Uma instncia da classe de origem, conjuntamente com um valor do qualificador, permiteseleccionar univocamente um subconjunto das instncias da classe destino. A multiplicidadeafecta o extremo destino. Os valores comuns so: 0..1 1 * . Ex. Banco (qualificador nconta) e Pessoa; Tabuleiro Xadrez linha/coluna --> Quadrado.

Associaes Reflexivas


28/35

Quando estabelece uma relao estrutural consigo prpria. Acontece quando uma classe temobjectos que desempenham diferentes papis. ex. ocupante do carro : condutor e passageiro.

Classes-AssociaoA associao pode tambm ter os seus prprios atributos (e eventualmente operaes), devendopor conseguinte ser modelada tambm como uma classe. Ex. classe-associao Tarefa que traduzida da associao entre pessoa e empresa. Representa-se por linha a tracejado a lig-la

linha da associao.

Associaes N-rias (N>=3)So pouco comuns, mas s vezes proporcionam melhor clareza. Esta associao representadapor losango com linhas para todas as classes participantes. A multipliciade mais complexa erepresenta o nmero de tuplos (instncias) numa associao quando os outros N-1 valores sofixos. Ex: Tarefa (Pessoa Empresa Tipo Tarefa). Podem ser decompostas em binrias atravsde esteretipos ou anotaes.

6.4. Interfaces um contrato na forma de uma coleco de especificaes de mtodos que providencia ummecanismo para separao clara entre a vista externa e a interna de um determinado elemento. realizada ou implementada por uma ou mais classes.Este conceito apresenta os seguintes benefcios ao nvel de programao:- Captura de semelhanas entre classes no relacionadas- Declarao de mtodos que uma ou mais classes esperam implementar- Um objecto pode ser visto de diferentes perspectivas (diferentes tipos) consoante ascircunstncias.

Representao GrficaComo uma classe mas com o esteretipo interface. Alternativamente pode ser um crculo.

Relaes Entre Interfaces, Classes e Componentes

Tal como nas classes, uma interface pode participar em relaes do tipo generalizao,associao, e dependncia. Adicionalmente pode participar em relaes do tipo realizao.Uma relao de realizao estabelece-se entre uma interface e uma classe ou entre umainterface e um componente. Pode representar-se na forma compacta ou expandida.Em funo do acesso ao componente (ou classe), assim so providenciadas diferentesfuncionalidades.Fundamental no desenvolvimento de software em componentes porque podemos evoluir ocomponente desde que continue a suportar os mesmos interfaces antigos.

6.5. Instncias e ObjectosUma instncia uma manifestao concreta de uma abstraco, qual um conjunto deoperaes pode ser aplicado, e que tem um estado que regista os efeitos das operaes

realizadas. Objecto no bem a mesma coisa que instncia (+ geral).Um objecto uma instncia de uma classe, herdando todos os atributos e mtodos definidos naprpria classe e possuindo uma representao de execuo prpria, a qual se pode designargenericamente por estado, bem como uma identificao nica no contexto da execuo.Tambm representado por rectngulo com 1,2 ou 3 seces. So, contudo, sublinhados nonome e sufixados pelo nome das classes respectivas:Nome-do-objecto : Nome-da-classe

OperaesOs objectos podem efectuar operaes definidas nas suas classes. ex: fac.CalculaIvaTotal()

EstadoO estado de um objecto dado pelos valores assumidos pelo conjunto de atributos de um objecto. dinmico e at pode ser associado a mquina de estados.


29/35


30/35

CAP. 7 UML MODELAO DO COMPORTAMENTO7.1. IntroduoEm qualquer sistema minimamente interessante, os objectos no esto estticos, mas interagementre si por troca de mensagens.A modelao do comportamento de um sistema de software consiste em 2 tipos distintos deespecificaes:- Modelao do comportamento interobjectos (diagramas de interaco)

- Modelao do comportamento intra-objecto, ou seja na identificao dos estados em que oobjecto pode estar ao longo do seu ciclo de vida, dos eventos envolvidos, ebm como dos seusalgoritmos (diagramas de estados e actividades)O UML providencia os seguintes elementos, que permitem a especificao do comportamentodum sistema:- objectos- interaces- mensagens- estados- eventos- sinais- actividades

7.2. Interaces a especificao do comportamento de um conjunto de instncias, representado pela sua trocade mensagens, num determinado contexto, e com vista concretizao de um objectivo.As interaces so usadas para modelar o fluxo de controlo de uma operao, classe,componente, caso de utilizao ou sistema na sua globalidade. Sempre que existe uma ligao(link) entre instncias, pode ocorrer uma ou mais interaces.Uma mensagem define uma comunicao particular entre instncias.Expls de comunicaes:- invocar uma operao;- lanar um sinal;

- construir ou destruir uma instnciaA mensagem especifica no s o tipo de comunicao mas tambm os papis do emissor e doreceptor, a aco lanada e o papel da ligao.

7.2.1. Objectos e LigaesOs diagramas de interaco podem ser considerados uma extenso dos diagramas de objectos.Uma ligao (link) entre objectos traduz a existncia de uma relao semntica ou estrutural entreas suas respectivas classes. Ligao representa-se por linha a cheio, no dirigida.

7.2.2 Mensagens e EstmulosUm estmulo uma comunicao entre 2 objectos que veicula informao com a expectativa quedeterminada actividade seja realizada. Ex. invocao de uma operao, envio de um sinal, criao

ou destruio de instncia.Uma mensagem a especificao de um estmulo, ou seja, especifica os papis que os objectosemissor e receptor devem acordar para que uma aco seja realizada.

7.2.3. Representao de MensagensUm estmulo representado por uma linha slida dirigida. H variantes para ilustrar diferentestipos de comunicao:- Simples Fluxo de controlo simples. Cada seta mostra o prximo passo numa determinadasequncia. Usa-se quando no relevante mostrar o tipo de comunicao. _____________>- Sncrona Invocao de mtodo ou outro fluxo de controlo, dentro do fluxo corrente. Pode serusado em situaes normais de invocao de operaes. Tambm entre objectos activosconcorrentes, quando invoca um sinal e espera que o comportamento destino termine.________seta a cheio- Assncrona alternativa simples, numa sequncia procedimental ___________meia seta- Retorno retorno de uma invocao de mtodo


31/35

Num fluxo de controlo procedimental a seta retorno deve ser evitada pois implcito. O valor deretorno (caso exista) ilustrado na seta inicial.Num fluxo de controlo no procedimental (ex. mensagens assncronas e processamento paralelo)o retorno deve ser explicitado.Num sistema concorrente a simples representa passar o fluxo para outra actividade (semnticabloqueante), enquanto a assncrona representa o envio de mensagem sem bloqueio.

7.2.4. Tipos de Mensagens- Call Invoca uma operao de um objecto (+ comum, comunicao sncrona)- Return Devolve resultado para objecto chamador- Send Envia sinal (assncrona)- Create cria objecto- Destroy

7.3. Diagramas de InteracoUma interaco representada por um diagrama de interaco. Pode usar-se para:- especificar a realizao de um caso de utilizao- operao envolvendo diversos objectosPodem ser apresentados de 2 formas:- Diagrama de Sequncia nfase na ordenao temporal das mensagens trocadas- Diagrama de Colaborao nfase na organizao estrutural dos objectos que trocam...Os 1s so mais usados para detalhar caso de utilizao e mais adequados para:- especificar situaes complexas- mltiplos e concorrentes fluxos de controloOs 2s so mais adequados para fluxos no concorrentes (sequenciais e procedimentais)Uma coleco de restries standard usam-se para representar criao e destruio de objectosou ligaes durante determinada execuo: {new} {destroy} {transient}Podem introduzir-se vrias descries (ex. restries temporais, aces). Devem ser colocadas namargem esquerda ou direita ou junto s activaes ou transies que representam.

7.3.1. Diagramas de SequnciaIlustra uma interaco segundo uma viso temporal. Tem 2 dimenses: horizontal objectos;vertical tempo.A seta pode ser inclinada se o tempo de envio do estmulo no negligencivel.

7.3.2. Diagramas de ColaboraoIlustra interaco organizada espacialmente. Mostra as relaes entre objectos quedesempenham diferentes papis.Como no mostra o tempo, a sequncia de interaces e de actividades concorrentes representada usando-se nmeros sequenciais.Pode ser representado por 2 formas:- Nvel de especificao : ilustra os papis que as classes e associaes desempenham, bem

como as suas mensagens- Nvel de Instncia : ilustra objectos, ligaes e estmulos.Ex. 7.1. Diagramas de Colaborao Pessoa com Distintos Papis (prof, alunos)

7.3.3. H equivalncia semntica entre os diagramas de sequncia e de colaborao.

7.3.4. Diagramas de Interaco e de Casos de UtilizaoNo ex. 7.2 vimos uma das utilizaes dos diagramas de interaco: modelar ao nvel do desenhouma ou um conjunto de interaces entre vrias instncias.Outra das aplicaes tpicas a especificao de um caso de utilizao, como complemento linguagem natural. Ex. Mquina de bebidas.O que interessa identificar os objectos envolvidos e a sequncia de aces.

7.4. Diagrama de Estados (statechart, diagrama de transio de estados, mquina de estados)


32/35

Permite modelar o comportamento interno de um determinado objecto, subsistema ou sistemaglobal.Representam os possveis estados de um objecto, as correspondentes transies de estados, oseventos que fazem desencadear as transies, e as operaes (aces e actividades) que soexecutadas dentro dos estados ou nas transies. Os objectos evoluem ao longo do tempoatravs de um conjunto de estados como resposta a eventos e passagem de tempo.Os estados so representados por rectngulos com os cantos arredondados, excepto o estado

inicial e final que tm cones prprios. As transies representam-se por uma linha a cheiodirigida. Pode ainda ser detalhado por uma seco com o nome e outra com as aces eactividades realizadas.

7.4.1. Estados uma situao registada por um objecto durante o seu respectivo ciclo de vida, durante a qualuma condio verificada, vai executando alguma actividade, ou simplesmente espera quedeterminado evento ocorra.Um estado tem diferentes partes:- Nome. Sem nome annimo- Aces de Entrada e de Sada- Transies Internas- Sub-Estados (disjuntos, isto , sequencialmente activos, ou concorrentes)- Eventos Deferidos: no so tratados no estado corrente

7.4.2. Transies uma relao entre 2 estados que especifica que um objecto que se encontre no primeiro estado,realizar um conjunto de aces e mudar para o segundo estado quando um determinadoevento ocorrer e determinadas condies se verificarem. descrita pela sintaxe:evento [condio com guarda] / acoTem diferentes partes:- O estado de origem e o estado de destino

- Evento de Gatilho- Condio de Guarda: expresso lgica- AcoPodem existir transies sem gatilho, quando o estado origem termina a sua actividadenormalmente. Pode ter mltiplos estados de origem (concorrentes)

7.4.3. Eventos uma ocorrncia de um estmulo que pode corresponder a uma transio de estado. H 4 tipos:- Sinais- Invocao- Passagem do tempo- Mudana de estado

Um sinal representa um objecto com nome que enviado (lanado) assincronamente por umobjecto e recebido (apanhado) por outro. Ex. mecanismo de excepes das linguagens.Um evento de invocao corresponde ao lanamento de uma operao tipicamente de modosncrono.A representao grfica igual mas o sinal tratado pela prpria mquina de estados e ainvocao por um mtodo.O evento passagem de tempo assinalado no diagrama pela palavra after seguida de umaexpresso, embora possa no se explicitar.O evento mudana de estado representa uma mudana de estado ou satisfao de determinadacondio e modeliza-se pela palavra-chave when seguida de expresso lgica.

7.4.4. Aces e ActividadesUma aco uma computao atmica (instantnea e no interrompvel). Ex. invocao demtodos, criao ou destruio de objectos, envio de sinal.


33/35

Podem especificar-se as aces de entrada prefixadas com entry e de sada com exit e aindarelativas a eventos desencadeados e tratados dentro do estado (notao evento / aco)Uma actividade uma computao no atmica, isto , que pode ser interrompida por outroseventos, complexa e eventualmente descrita por outro DE incluso. So os elementos bsicosdos diagramas de actividades. Quando fazem parte do DE so prefixadas com do.

7.4.5. Sub Estados

um conceito avanado dos DE e a ideia a abstraco.Um estado que tenha um conjunto de sub-estados mais detalhados um estado composto.Podem ser ortogonais (concorrentes) ou sequenciais (disjuntos).Ex. Diagrama de estados de um PC.

7.5. Diagramas de Actividades um caso particular de um diagrama de estados, no qual todos ou a maioria dos estados soestados de actividades e todas ou a maioria das transies so desencadeadas pela conclusodas actividades dos estados anteriores.Enquanto nos diagramas de interaco o foco na visualizao das mensagens trocadas entre osobjectos, nos diagramas de actividades a ateno incide na visualizao das operaesrealizadas pelos objectos intervenientes.Correspondem aos Fluxogramas.Contm:- Estados-Aco- Estados-Actividade (a diferena que podem ter partes adicionais)- Transies- Objectos

7.5.1. DecisesA tomada de deciso um mecanismo comum aos DE e DA que consiste em especificar queactividade deve ser realizada aps a execuo da actividade corrente, dependendo de umacondio de guarda.

7.5.2. Caminhos Concorrentes (e independentes)Ex. Acordar fork Tomar pequeno almoo; Fazer higiene matinal; Cumprimentar a famlia join. barra de sincronizao

7.5.3. Pistas (Swimlanes)Na modelao de processos de negcio comum a realizao de actividades por vriasentidades. O UML prope o conceito de pistas para agrupar as vrias actividades daresponsabilidade de cada entidade participante. Cada grupo separado por uma linha vertical.Cada pista corresponde a uma entidade do mundo real.Cada actividade pertence a uma pista, apenas as transies cruzam as pistas. Nos casos em que realizada por mais que uma entidade faz-se linha separadora em comum.

7.5.4. Actividades e ObjectosOs DA podem explicitar relaes entre actividades e objectos. Estas relaes de dependnciapermitem ilustrar o fluxo de um objecto ao longo de um conjunto de actividades, representadaspor linhas dirigidas a tracejado. Para alm disso ilustra ainda os seus papis, atributos e estado.Ex: :Oramento [aberto] [preparao] .....

7.5.5. Envio e Recepo de SinaisO UML adopta o conceito de evento de envio (output event) e de recepo (input event). Permiteexplicitar:- Relaes de dependncia: seta dirigida a tracejado entre os eventos de envio e de recepo desinal) entre distintas mquinas ou distintos diagramas de actividades pela troca de eventosassncronos.- Dentro da mesma mquina de estados, eventos que devero ocorrer durante as respectivastransies de esatdos/actividades.


34/35

Evento de emisso polgono convexo.

7.5.6. Utilizaes TpicasOs DA so usados para modelar o sistema como um todo, um subsistema, uma operao ou deuma classe. Tambm se pode associar a um caso de utilizao ou colaborao.No entanto so usados principalmente para:- Especificar Operaes: Fluxogramas de algoritmos --> tomada de deciso, fork, joint

- Especificar workflows ou processos de negcio: Identificao dos actores e correspondentecolaborao com o sistema --> pistas e modelao dos fluxos de objectos.Ex. 7.5 DA da operao de Fibonacci; 7.6 Da da disseminao de eventos no WebDEI


35/35

CAP. 8 UML MODELAO DA ARQUITECTURA8.1. Introduo a aparte mais limitada, mal explorada e compreendida do UML.Os diagramas de arquitectura (ou de implementao) descrevem aspectos da fase deimplementao e instalao de um sistema de software, designadamente:- Estrutura e dependncias de cdigo fonte e de mdulos executveis- Respectiva instalao nas diferentes plataformas computacionais subjacentes.

Apresentam-se em 2 formas:- Diagramas de Componentes- Diagramas de InstalaoOs 1s so usados na perspectiva dos seus componentes digitais, explicitando principalmente assuas mltiplas dependncias.Os 2s so usados na perspectiva dos seus componentes fsicos, explicitando as suasdependncias de comunicao. Permitem ainda identificar quais so os componentes instaladosem cada n computacional.

8.2. Componentes e NsUm componente uma pea bsica na implementao de um sistema. ex. ficheiros de cdigo(fonte, binrio ou executvel) ou ficheiros de documentos relativos ao negcio.H 3 tipos distintos:- Componentes de Instalao: Base dos sistemas executveis (DLL, executveis, controlosActiveX, classes Java)- Componentes de Trabalho: Ficheiros de cdigo fonte, de dados, documentos. So a base dos deinstalao- Componentes de Execuo: criados como resultado da execuo dum sistema (processos,Threads, agentes de software)

Parte i Cap. 1 – Enquadramento e

Documents

Transcript of Parte i Cap. 1 – Enquadramento e