Hlio Engholm Jr.

Novatec

Copyright 2013 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. proibida a reproduo desta obra, mesmo parcial, por qualquer processo, sem prvia autorizao, por escrito, do autor e da Editora. Editor: Rubens Prates Capa: Carolina Kuwabata Reviso gramatical: Marta Almeida de S Editorao eletrnica: Carolina Kuwabata ISBN: 978-85-7522-340-6 Histrico das impresses: Junho/2013 Primeira edio

Novatec Editora Ltda. Rua Lus Antnio dos Santos 110 02460-000 So Paulo, SP Brasil Tel.: +55 11 2959-6529 Fax: +55 11 2950-8869 E-mail: novatec@novatec.com.br Site: novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec
MP20130603

CAPTULO 1

Introduo modelagem orientada a objetos

Historicamente, temos um cenrio que registra muitos problemas e falhas em projetos de desenvolvimento de software, como tambm nos produtos por eles entregues aos clientes que contratam empresas e prossionais, para o desenvolvimento de softwares customizados para suas necessidades especcas. Entre essas falhas podemos citar a demora na entrega dos artefatos do projeto, a falta de qualidade desses, as diculdades encontradas na manuteno do software entregue, o desempenho desse aqum das expectativas dos contratantes e a falta de conabilidade nos resultados apresentados. Esse histrico demonstra a necessidade de melhoria nos processos de desenvolvimento de software utilizados pelas empresas de tecnologia da informao contratadas para esse m, como tambm na qualidade dos produtos por elas desenvolvidos e entregues. As empresas desenvolvedoras de software necessitam de mecanismos que permitam maior produtividade e qualidade dos produtos desenvolvidos. Existem diversas disciplinas que, em conjunto, permitem obter esses objetivos. Este livro aborda as disciplinas relacionadas anlise e ao design orientados a objetos, que so extremamente importantes no desenvolvimento de software mais robusto, ecaz e com maior qualidade e extensibilidade. So apresentados conceitos introdutrios de modelagem de sistemas e vrios aspectos considerados nas fases de anlise, design e implementao de software, fases essas contidas em metodologias de desenvolvimento de software utilizadas no mercado.

14

Captulo 1 Introduo modelagem orientada a objetos

15

Com esta apresentao, tenta-se demonstrar a importncia da utilizao de modelagem e design na construo de sistemas ao apresentar as vantagens de utiliz-los juntamente com as melhores prticas de mercado relacionadas ao desenvolvimento de software. Tambm procura-se demonstrar a importncia do levantamento e gerenciamento ecaz dos requisitos nos projetos para que esses sejam bem-sucedidos. O desenvolvimento de software sem utilizao de processos denidos, orientao a objetos e melhores prticas pode trazer uma srie de consequncias negativas ao produto nal do desenvolvimento de software. Entre elas, podemos citar: softwares de difcil manuteno, tanto corretiva quanto evolutiva; dificuldade de se reutilizar cdigo que foi desenvolvido, permitindo a reutilizao de cdigo mal-elaborado, sujeita gerao e propagao de erros em outras partes do sistema em desenvolvimento; sistemas com baixa performance e escalabilidade inadequada; baixa eficincia no desenvolvimento, com analistas desenvolvendo as mesmas funcionalidades diversas vezes; falta de confiana nos dados apresentados pelo sistema, fazendo com que usurios deixem de utilizar o sistema por no conarem nas informaes apresentadas; baixa qualidade do cdigo-fonte; implantao de sistemas repletos de erros, constantemente entrando em manuteno e interrompendo o trabalho dos funcionrios, atendimento a clientes e/ou funcionalidades disponibilizadas a clientes; sistemas que podem no atender s expectativas dos stakeholders; softwares com alto custo de manuteno; softwares de difcil utilizao, que no atendem s necessidades dos stakeholders; grande insatisfao dos usurios; prejuzos de imagem junto a clientes; fracasso do projeto.

16

Anlise e Design Orientados a Objetos

Nessa relao de consequncias negativas, a depreciao da imagem dos prossionais envolvidos e da empresa em que eles trabalham possui um valor imensurvel, podendo trazer grandes diculdades na intensicao e prospeco de novos negcios para todos os envolvidos. Um dos objetivos primordiais deste livro o de aumentar a competncia dos leitores na entusiasmada tarefa de se realizar o design ecaz de sistemas, produzindo-se um software de maior qualidade, reutilizvel e escalvel.

1.1 Perspectiva do cliente

Clientes geralmente esto preocupados com os benefcios que os sistemas traro ao seu negcio e ao seu dia a dia, considerando quais funcionalidades esses sistemas oferecem, se existir reduo de custos operacionais com a sua utilizao e de que maneira eles iro agilizar e facilitar seus trabalhos dirios. A princpio, eles no possuem e nem desejam possuir conhecimentos tcnicos relacionados ao processo de desenvolvimento de sistemas. Por isso cabe aos prossionais de TI garantir que a equipe de desenvolvimento e de qualidade tenha todas as informaes necessrias e uma viso clara do que dever ser desenvolvido, para que seja entregue ao cliente a soluo desejada e com a qualidade por ele esperada. Alm dos requisitos de negcio denidos pela rea de negcios das empresas, os clientes tambm desejam aqueles requisitos que so conhecidos como no funcionais, apesar de a maioria deles no conhecer essa denio. Requisitos no funcionais so aqueles que impem restries e denem atributos de qualidade ao sistema, tais como velocidade de processamento e respostas rpidas, facilidade na manuteno do cdigo, capacidade de atender a centenas ou milhares de usurios conectados ao mesmo tempo. A seguir enumeramos os requisitos no funcionais normalmente conhecidos e percebidos pelos usurios nais. Usabilidade: considera a facilidade de uso do sistema pelos usurios. Confiabilidade: considera o quo convel a utilizao do sistema, representando a conabilidade das informaes apresentadas e

Captulo 1 Introduo modelagem orientada a objetos

17

mostrando se ele possui mecanismos de proteo para situaes de contigncia, como backup de dados e tempo de retorno operao. Desempenho: relacionado ao desempenho esperado do sistema. Para um projeto ser bem-sucedido, a equipe que o desenvolve deve ter o escopo do projeto muito bem denido. Aqui entra uma rea de conhecimento muito importante para que projetos sejam bem-sucedidos: o levantamento e gerenciamento de requisitos juntamente com o controle efetivo de mudanas. Para o cliente importante que o sistema atenda s suas necessidades, realizando suas funcionalidades rapidamente e produzindo resultados conveis. Para ele no importam os aspectos tcnicos envolvidos no desenvolvimento da soluo nem os aspectos de manuteno do sistema em produo. Imagine que o cliente precisa vericar se o seu cliente tem alguma restrio no Serasa. Ele apenas deseja digitar o CPF dessa pessoa em alguma interface e executar a consulta. Geralmente ele no est interessado em saber como essa consulta ser tecnicamente implementada, ele deseja apenas ter essa funcionalidade para uso em seu dia a dia e espera que o resultado esteja correto e seja fornecido sempre o mais rpido possvel. Esse exemplo demonstra a necessidade de existir um processo de renamento de requisitos, em que o analista de requisitos deve especicar cenrios operacionais com base nas necessidades dos interessados, analisando-se o documento de viso e os requisitos funcionais. Os cenrios operacionais representam uxos completos de operao para os usurios nais. Existem algumas caractersticas relacionadas a sistemas que so desejadas pelos clientes em geral. Dentre elas, podemos citar: menor custo de propriedade; menor tempo de espera para se obter o sistema; maior qualidade do sistema; fidedignidade das informaes apresentadas e das operaes realizadas; confiabilidade; maior disponibilidade.

18

Anlise e Design Orientados a Objetos

Os softwares possuem uma caracterstica intrnseca que aumenta os custos das empresas ao adquirir, utilizar e manter sistemas em operao conhecida como custo total de propriedade. Esse custo conhecido em ingls como TCO (Total Cost of Ownership) e aquele que a empresa assume ao manter um sistema em utilizao por seus funcionrios. Imagine uma empresa que pretende utilizar determinado software em 500 estaes de trabalho, sendo que esse sistema deve ser instalado e congurado em cada uma delas por um analista de suporte. Agora imagine que a instalao leva cerca de uma hora e que a empresa no utiliza nenhuma soluo de mercado para instalao e atualizao automtica de software. Nesse cenrio, torna-se fcil imaginar o custo envolvido na instalao e congurao desse aplicativo para uso na empresa. Agora imagine que o sistema apresenta algum problema de funcionamento ou que foi gerada uma nova verso contendo novas funcionalidades ou alterando as j existentes. Novamente ser necessrio contratar prossionais para realizar a atualizao em todas as mquinas. Isso faz parte do TCO, e todas as empresas tm por objetivo diminuir esse custo. Outro detalhe que os clientes nunca querem ou nunca podem esperar muito tempo para que a soluo que disponvel para ser utilizada, deixando clara a necessidade de usar procedimentos para agilizar o desenvolvimento e a manuteno de sistemas. A disciplina de anlise e design orientada a objetos pode auxiliar signicativamente a equipe a atingir objetivos comuns a todos os clientes.

1.2 Perspectiva dos analistas e desenvolvedores

Ao contrrio dos clientes e das reas de negcio, os analistas e desenvolvedores envolvidos no projeto precisam, alm da viso clara do problema de negcio que deve ser resolvido, da viso tcnica de como o software dever ser desenvolvido e tambm do planejamento da soluo que dever ser desenvolvida. Os analistas envolvidos nesse planejamento precisam visualizar e comunicar os detalhes de seu planejamento e a soluo proposta a uma variedade de envolvidos com pers distintos, desde seus clientes at os envolvidos na construo e nos testes do sistema.

Captulo 1 Introduo modelagem orientada a objetos

19

Nas ltimas dcadas, tivemos vrias propostas para documentar, modelar e desenvolver sistemas. Este livro aborda o paradigma orientado a objetos (POO) e a linguagem de modelagem unicada (UML Unied Modeling Language) em todos os exemplos e nas prticas relacionadas anlise e ao design de sistemas. Esse tipo de modelagem nos permite criar solues elegantes, compartilhar ideias e acompanhar as solues em desenvolvimento por todo o ciclo de desenvolvimento de software. Em empresas que possuem uma metodologia de desenvolvimento de sistemas institucionalizada com responsabilidades denidas, geralmente h desenvolvedores que possuem a tarefa de implementao do software e que deveriam receber especicaes completas do que ser desenvolvido e de como ser desenvolvido. Essas especicaes devem fornecer todas as informaes que o programador necessita para elaborar o cdigo e so desenvolvidas por prossionais que devem se preocupar em especicar o sistema para corresponder no s aos requisitos que atendem s reas de negcio do cliente, mas tambm aos requisitos no funcionais. Alm dos requisitos no funcionais comentados anteriormente, os desenvolvedores devem se preocupar com outros no visualizados pelos usurios, como por exemplo: Escalabilidade: como a arquitetura do sistema suporta o aumento da concorrncia dos recursos do prprio sistema. Suportabilidade: existncia de diferentes sistemas operacionais ou plataformas, processamento distribudo, diferentes protocolos de comunicao. Restries de projeto: associadas a plataformas e/ou tecnologias a serem utilizadas. Requisitos de implementao: associados a restries relacionadas ao cdigo ou construo do sistema. Requisitos de interface: caractersticas especiais para integrao com outros sistemas ou de interface operacional com usurios humanos. Requisitos fsicos: associados a requisitos de hardware, tais como conguraes fsicas de rede.

20

Anlise e Design Orientados a Objetos

Na verdade, estamos falando sobre tarefas relacionadas modelagem e construo de software. Em uma matriz de responsabilidades, cabe aos prossionais de anlise e design denir como o sistema deve ser construdo para se atingir os objetivos relacionados tanto aos requisitos de negcio quanto aos requisitos no funcionais, sendo que os desenvolvedores devem construir o cdigo utilizando-se das especicaes criadas por aqueles prossionais.

1.3 Processo de modelagem. Para que modelar?

O desenvolvimento de sistemas est sempre associado resoluo de um problema ou de uma necessidade em uma situao real, alm da automao de processos, por meio de programas de computador. Nesse sentido, a tarefa de representar um fato real para ser tratado por um programa de computador torna-se um trabalho extremamente oneroso e complexo, caso se deseje faz-lo considerando todos os detalhes do mundo real. A modelagem nada mais do que a representao de situaes reais usando modelos simplicados que, quando utilizados, trazem resultados ecazes no desenvolvimento do produto nal do projeto. Esses modelos simplicados devem nos mostrar o sistema por vrios pontos de vista, assim como um projeto de arquitetura, que apresentado com imagens em diferentes perspectivas. No processo de modelagem, os prossionais utilizam apenas as caractersticas do processo real que so de fato relevantes ao problema, ignorando todas as outras, a m de deix-lo o mais simples possvel, sem complic-lo com fatos desnecessrios ao problema que deve ser resolvido. Desse modo, o processo de modelagem sempre gera uma viso simplicada dos problemas. Por meio da modelagem possvel gerar um modelo simplicado e eciente que represente o problema real que o sistema dever resolver. Esse modelo dever servir de base para o desenvolvimento do produto nal. Por exemplo, em um projeto de um sistema bancrio, podemos concluir que muitas informaes dos clientes so irrelevantes para determinadas funcionalidades, por exemplo, o mapeamento gentico dos clientes irrelevante para todas as funcionalidades conhecidas atualmente nesses

Captulo 1 Introduo modelagem orientada a objetos

21

sistemas, no agregando nenhum valor para o negcio do cliente. Desse modo, em nosso sistema e nos dados por ele armazenados, em momento algum ser considerado esse mapeamento. Com relao s aes do objeto cliente, nosso modelo de desenvolvimento vai considerar apenas as aes que agregam valor ao sistema a ser desenvolvido, tais como realizar depsito, sacar dinheiro ou aplicao nanceira e realizar transferncias monetrias, desconsiderando as aes de andar ou falar, que no agregam valor ao sistema que ser desenvolvido. Considere o modelo como parte da especicao do que dever ser desenvolvido, mostrando todas as caractersticas do produto nal que agregam valor a esse. De fato, a modelagem aparece em vrias disciplinas das reas de conhecimento humano e utilizada por toda a indstria. Lembre-se, por exemplo, da fsica quando estudamos o modelo de movimento retilneo uniforme. Esse tipo de movimento somente existir se for criado articialmente pelo ser humano, mas pode trazer resultados satisfatrios em algumas situaes especcas.

1.4 Processo de Levantamento e Gerenciamento de Requisitos

Os requisitos so importantes desde o incio do projeto at a sua fase de homologao. Nenhuma equipe pode iniciar seus trabalhos de construo nem ter condies de avaliar e testar algo de que no tenha conhecimento prvio. Eles devem descrever todos os aspectos relacionados ao produto de software a ser desenvolvido, desde aspectos relacionados s funcionalidades previstas para os usurios at os relacionados performance, escalabilidade, manuteno, segurana, extenso e usabilidade, entre outros. O levantamento de requisitos , na verdade, um processo evolutivo. Esse processo pode ter como fonte inicial uma Declarao de Trabalho ou um Request for Proposal enviado para a empresa, solicitando uma proposta de desenvolvimento de uma soluo de software. Desse modo, os requisitos evoluem durante o andamento do projeto, partindo dos requisitos iniciais e evoluindo por meio de entrevistas junto s fontes de requisitos e de mudanas sofridas durante o projeto. Esse processo de evoluo do escopo do projeto refora a necessidade do gerenciamento ecaz dos requisitos do projeto, disciplina prevista no gerenciamento de projetos.

22

Anlise e Design Orientados a Objetos

Uma certeza do desenvolvimento de software que requisitos sempre mudam. Apesar de bem-vindas, as mudanas causam alteraes no produto nal do projeto e precisam ser gerenciadas adequadamente e aprovadas formalmente pelo cliente antes de serem atendidas. Essa necessidade fez surgir no desenvolvimento de software a disciplina de Gerenciamento de Mudanas, que controla de forma ecaz todas as mudanas solicitadas no projeto. Como ponto de partida, pergunta-se: quem est solicitando a alterao possui autoridade para solicitar mudanas? Caso tenha, essa pessoa deve se apresentar ao responsvel pelo projeto no cliente e a quem tem autoridade para tomar decises, e devem ser avaliados os impactos nos custos, prazos e riscos e tambm a qualidade da alterao que est sendo solicitada. E somente com o De Acordo formal do cliente pode-se ento dar incio implementao das mudanas. Outro aspecto importante relacionado a requisitos garantir que o escopo do projeto no seja alterado com a incluso aleatria de requisitos adicionais sem um controle adequado de mudanas. A delimitao das fronteiras do sistema essencial para prevenir a incluso de requisitos relacionados a outros sistemas. Com relao ao escopo de projetos, preciso se proteger de dois efeitos conhecidos internacionalmente como Scope Creep e Golden Plating. Scope Creep e Golden Platen ocorrem quando pessoas envolvidas no projeto decidem adicionar descontroladamente funcionalidades e requisitos no previstos no escopo inicial do projeto sem realizar o processo formal de gerenciamento de mudanas. A no utilizao dessa disciplina pode permitir que funcionalidades no alinhadas aos objetivos do projeto sejam adicionadas a ele, podendo ameaar o prazo, a qualidade, os custos envolvidos e a satisfao do cliente. Desse modo, deve-se levar em considerao um lema de mercado: no importa quo pequeno seja nosso projeto nem quo pequena seja a mudana, o processo de gerenciamento de mudanas deve sempre existir . De acordo com o relatrio de 2010 da agncia inglesa Arras People, de gerenciamento de programas e projetos, scope creep responsvel por 11,8% dos fracassos de projetos. Devemos nos lembrar de que a qualidade do produto que est sendo desenvolvido est diretamente relacionada ao que foi solicitado e especicado pelo cliente.

Captulo 1 Introduo modelagem orientada a objetos

23

O processo de levantamento de requisitos deve vericar os objetivos do projeto e todas as particularidades a serem disponibilizadas pelo sistema a ser desenvolvido, com a preocupao de que o sistema atenda s necessidades e expectativas da empresa.

1.5 Paradigma Orientado a Objetos

Utilizaremos o Paradigma Orientado a Objetos nas tcnicas relacionadas anlise e ao design de sistemas apresentadas neste livro. O foco desse paradigma no est nos procedimentos que o sistema ir contemplar ou nas informaes que ele ir manipular e/ou armazenar, mas, sim, nos objetos que se relacionam para gerar o valor esperado pelo cliente. Esse tipo de abordagem diferente das abordagens utilizadas no modelo proposto pela anlise e pelo design estruturado e da abordagem utilizada em diagramas entidade relacionamento, por exemplo. O Desenvolvimento de Software Orientado a Objetos (DSOO) utiliza esse paradigma nas fases de anlise, design e implementao do sistema envolvido no projeto. A utilizao desse paradigma tida atualmente como a melhor estratgia para reduzirmos a diculdade recorrente no processo de modelagem do mundo real do domnio do problema, por meio de um conjunto de componentes de software que seja o mais el na representao desse domnio. O captulo 5 explica os conceitos de orientao a objetos e sua aplicabilidade no desenvolvimento de sistemas.

1.6 UML e o ciclo de desenvolvimento de software

A linguagem unicada de modelagem (Unied Modeling Language UML) foi criada por Jim Rumbaugh, Grady Booch e Ivar Jacobson, na tentativa de disponibilizar ao mercado uma nova linguagem de modelagem orientada a objetos que pudesse ser adotada como um novo padro de linguagem de modelagem. Foi aprovada como um padro pela OMG (Object Management Group) em 1997 e tem sido utilizada desde ento em projetos de desenvolvimento orientados a objetos.

24

Anlise e Design Orientados a Objetos

A UML fornece diagramas de modelagem que podem ser utilizados nos processos do ciclo de desenvolvimento de software, documentando e especicando o sistema. uma linguagem utilizada para documentar, especicar e at construir softwares, caso sejam utilizadas ferramentas adequadas para tal como o Enterprise Architect da Sparx Systems. A seguir sero tratados os diagramas que podem ser utilizados nos processos existentes no ciclo de desenvolvimento de software.

1.6.1 Diagramas de caso de uso

Utilizados nas fases de levantamento de requisitos, anlise e design, os diagramas de caso de uso mostram as funcionalidades do sistema e seus usurios, conhecidos na UML como atores do sistema. Esses usurios podem ser usurios humanos ou outros sistemas que estejam integrados ao mesmo, fornecendo ou consumindo funcionalidades e/ou recursos do mesmo. Devido ao fato de os diagramas de casos de uso mostrarem gracamente todas as funcionalidades a serem contempladas no sistema, eles podem ser considerados como um contrato com o cliente. Depois de devidamente aprovados por eles, tudo o que no estiver representado nesses diagramas no faz parte do escopo do projeto, devendo ser tratado como mudana de escopo, impactando, portanto, nos prazos, custos e riscos do projeto. A gura 1.1 mostra um exemplo de um diagrama de caso de uso, relacionado a um sistema utilizado em um restaurante ctcio. Esse exemplo mostra apenas casos de uso necessrios para uma funcionalidade relacionada ao encerramento da conta de uma determinada mesa.

Figura 1.1 Diagrama de casos de uso de um sistema de restaurante.

Captulo 1 Introduo modelagem orientada a objetos

25

1.6.2 Diagramas de atividades

So utilizados na fase de levantamento de requisitos e na fase de design para identicar uxos de processos dentro do sistema, mostrando o uxo de controle de uma atividade para outra dentro das funcionalidades do sistema. Esse diagrama mostra usurios e atividades, permitindo a visualizao dos pers de usurio do sistema. A gura 1.2 mostra um exemplo de diagrama de atividades.

Figura 1.2 Diagrama de atividades de caso de uso Encerrar conta de restaurante.

Observe como extremamente simples entender o uxo de atividades existentes em determinada funcionalidade. Esse tipo de diagrama facilmente entendido por qualquer pessoa que o visualize. Podemos utiliz-lo para atender a vrios objetivos, tais como compreender o que o cliente deseja, documentar o sistema, orientar o programador sobre a maneira que a funcionalidade dever ser implementada e a equipe de testes sobre como o sistema dever responder.

26

Anlise e Design Orientados a Objetos

Observe que esse diagrama exemplo identica a matriz de responsabilidades das funcionalidades. Isso permite que o programador e o homologador saibam exatamente quem dever executar o qu.

1.6.3 Diagrama de classes

O diagrama de classes um dos mais importantes do paradigma orientado a objetos e pode ter sua denio iniciada j na fase de anlise, apenas identicando as classes candidatas. Esse diagrama registra o modelo de domnio da aplicao, especicamente o relacionamento dos objetos de dados com o sistema, o relacionamento entre eles e as operaes que cada um deles pode executar. Modelo de domnio considerado como sendo as abstraes-chave do sistema, mostrando o relacionamento ou a colaborao entre elas. O captulo 7 apresentar e tratar esse assunto com detalhes. As classes podem ser vistas como templates de objetos similares, possuindo os dados e as aes dos objetos que elas representam. Desse modo, classes capturam os objetos em detalhes. A gura 1.3 mostra um diagrama de classes candidatas de nossa modelagem do sistema para restaurantes, cujo diagrama de casos de uso foi apresentado no item 1.6.1. Chamamos de classes candidatas devido ao fato de a modelagem ser um processo evolutivo, onde novas classes aparecem e outras podem se mostrar desnecessrias.

Figura 1.3 Diagrama de classes candidatas de sistema para restaurantes.

1.6.4 Diagrama de sequncia

algumas vezes utilizado na fase de levantamento de requisitos, mas normalmente produzido na fase de design para mostrar objetos em movimento e a interao entre eles, ajudando a documentar e a fazer entender o relacionamento entre os objetos do sistema.

Captulo 1 Introduo modelagem orientada a objetos

27

Esse diagrama pode ser muito til na disciplina de testes ao se criar planos de teste e executar testes no sistema. Como todo diagrama UML, ele pode ser to completo ou to simplicado quanto se julgue necessrio. A gura 1.4 mostra um exemplo desse diagrama em nosso exemplo de modelagem, relacionado ao sistema desenvolvido para restaurantes e lanchonetes. Observe que esse diagrama mostra o relacionamento dos objetos levantados para o caso de uso e as respectivas classes que faro parte do sistema.

Figura 1.4 Diagrama de sequncia do caso de uso Encerrar conta de restaurante.

1.6.5 Diagrama de colaborao

De maneira semelhante ao diagrama de sequncia, o diagrama de colaborao mostra a colaborao dinmica entre objetos, sendo mais apropriado para os casos onde se desejar dar nfase ao contexto do sistema. Esse diagrama mostrado como um diagrama de relacionamento de objetos, dando nfase s mensagens trocadas entre objetos. A gura 1.5 mostra um exemplo de diagrama de colaborao de caso de uso relacionado matrcula de aluno em um curso. Na prtica, existem ferramentas de mercado que apenas com um comando transformam o diagrama de sequncia no de colaborao, e vice-versa.

28

Anlise e Design Orientados a Objetos

Figura 1.5 Diagrama de colaborao de cadastro em matrcula de curso.

1.6.6 Diagrama de pacotes

Pacotes so utilizados na organizao de modelos, diagramas e objetos/ componentes de nossa aplicao. Na implementao dos sistemas orientados a objetos tornam-se espaos conhecidos em ingls como namespaces, responsveis por armazenar uma srie de objetos agrupados para utilizao pela aplicao a ser disponibilizada como produto nal. Devemos incluir em nosso cdigo em implementao os pacotes que possuem determinado objeto para podermos utiliz-lo. Como exemplo, imagine que cou denido no design da aplicao que um determinado componente para validao de CPFs de nome CPFBean deva estar no pacote utilPackage. A fim de utilizar aquele componente, precisamos incluir em nosso cdigo esse pacote para que ele possa ser localizado pela aplicao. A gura 1.6 mostra um exemplo simplicado de diagrama de pacotes e a gura 1.7, o detalhamento do pacote Sistema, mostrando algumas das classes denidas dentro desse pacote que sero transformadas em objetos para utilizao pela aplicao.

Captulo 1 Introduo modelagem orientada a objetos

29

Figura 1.6 Exemplo de diagrama de pacotes.

Figura 1.7 Detalhamento do pacote Sistema.

1.6.7 Diagrama de implantao

Elaborado na fase de design para indicar como o sistema dever ser implantado e hospedado, mostrando como os recursos sero distribudos pelos recursos fsicos de hardware. A gura 1.8 mostra um exemplo desse diagrama mostrando, inclusive, detalhes de hardware a serem utilizados para implantao do sistema.

30

Anlise e Design Orientados a Objetos

Figura 1.8 Diagrama de implantao.

1.6.8 Diagramas por fase

Para a fase de anlise, os diagramas de caso de uso e de atividades geralmente so mais que o suciente e ajudam na documentao do sistema e na validao do entendimento do problema a ser atendido pela soluo. J para a fase de design podemos ter os diagramas de classe e sequncia, sendo que, quando justicvel, tambm o de estado e de pacotes. Devemos nos lembrar de que os extremos so ruins. No ter diagrama nenhum e ter todos os diagramas so extremos indesejados. No primeiro caso, devido ausncia de modelos que representam a soluo a serem utilizados no entendimento do projeto, e no segundo, devido ao tempo e ao custo relacionados ao desenvolvimento de todos os diagramas.

1.7 Processo de desenvolvimento de software

O desenvolvimento de software pode ser visto como uma srie de transformaes que, iniciando no modelo mental dos envolvidos no projeto (stakeholders), resulta no sistema a ser entregue ao cliente. A figura 1.9 mostra a sequncia de transformaes que, partindo do modelo mental dos envolvidos no projeto, gera o cdigo como produto nal. O ponto de partida de alguns projetos um artefato conhecido no mercado como Declarao de Trabalho, que mostra em alto nvel os objetivos e macrorrequisitos do projeto. Esse documento originado pelo

Captulo 1 Introduo modelagem orientada a objetos

31

patrocinador ou iniciador do projeto normalmente descreve as necessidades, os produtos ou servios que devero ser providos como resultado nal do projeto.

Figura 1.9 Transformao do modelo mental para o sistema nal.

Em projetos externos, esse documento pode ser recebido pelas empresas de desenvolvimento de software como parte de um processo de licitao para contratao do desenvolvimento. Se existente, esse documento elaborado antes de o projeto ser iniciado deve ser considerado como artefato de entrada no processo de levantamento e renamento de requisitos. O apndice A apresenta um exemplo de Declarao de Trabalho relacionado ao estudo de caso utilizado nos exemplos do livro, relacionado ao Banco Omega, um banco familiar ctcio que se encontra em crescimento e precisa automatizar gradativamente suas operaes bancrias. Processos de desenvolvimento de software tradicionalmente incluem os seguintes subprocessos: elicitao de requisitos; anlise dos requisitos; arquitetura; design; implementao; testes; implantao. A seguir sero apresentados detalhes introdutrios das fases de anlise, arquitetura e design envolvidas no desenvolvimento de sistemas orientados a objetos (DSOO). A partir do captulo 6, veremos com detalhes essas trs fases que ocorrem nos processos no Ad hoc de desenvolvimento de sistemas (Modelos informais utilizados pelo desenvolvedor de software).

32

Anlise e Design Orientados a Objetos

1.7.1 Fase de anlise

Na fase de anlise preciso ter uma ideia muito clara do problema de negcio a ser tratado e tambm do que deve ser feito, sem se preocupar com a questo de como o software ser implementado e de quais so suas caractersticas tcnicas. Entre as diversas tarefas previstas para esta fase, podemos enumerar: estabelecer uma viso clara do problema de negcio; verificar as tarefas que o sistema deve contemplar; entender o vocabulrio do cliente; levantar os recursos existentes no cliente (plataforma, bancos de dados, sistemas legados que podem necessitar de integrao com o novo sistema etc.) ; verificar a melhor soluo para o problema de negcio; definir tarefas. J nesta fase podemos utilizar a UML como linguagem para documentar e divulgar as informaes adquiridas pela equipe do projeto. Daremos exemplos disso no captulo 6. Em uma fase de anlise orientada a objetos, podemos identicar os objetos candidatos e a interao entre eles, identicar objetos que possam armazenar regras de negcio do sistema, distribuir o comportamento de funcionalidades entre objetos, identicar aqueles que podem realizar fluxo de eventos como workflows e elaborar o diagrama de classes inicial do sistema. Todo o resultado desse trabalho ser utilizado como ponto de partida para a fase de design do sistema.

1.7.2 Arquitetura de software

As mudanas relacionadas Engenharia de Software tm aumentado a importncia da arquitetura de software para garantir aspectos relacionados a requisitos no funcionais, como escalabilidade, desenvolvimento de aplicaes distribudas e performance.

Captulo 1 Introduo modelagem orientada a objetos

33

A arquitetura possui um nvel de abstrao mais alto que o design, o qual se preocupa em projetar os detalhes da aplicao. Enquanto o design se preocupa com os requisitos funcionais, a arquitetura se preocupa com os requisitos no funcionais. Nesse processo, o arquiteto de software deve propor uma arquitetura para o sistema. Devido ao fato de haver vrios tipos de arquitetura, essa deciso deve se basear em quesitos como: plataformas utilizadas pela empresa e se elas estaro integradas com a nova soluo a ser desenvolvida; tipo de plataforma que a empresa deseja utilizar; sistemas legados aos quais o novo sistema poder ou dever ser integrado; tipo de interface que se deseja utilizar para os usurios do sistema; onde o sistema ser hospedado; caso necessrio, tipo de distribuio do sistema. Na seleo e denio da arquitetura, cabe ao arquiteto de software identicar os riscos relacionados aplicao a ser desenvolvida e analisar as opes de arquitetura, alm de analisar as opes que minimizem os custos do projeto sem deixar de atender s expectativas relacionadas a esse projeto. Tambm cabe a ele garantir que sua proposta de arquitetura atenda aos requisitos no funcionais do cliente, relacionados conabilidade, ao desempenho e escalabilidade pelo sistema a ser desenvolvido. Algumas vezes o cliente prefere correr algum risco do que arcar com os custos associados eliminao dos riscos identicados. Imagine o custo relacionado duplicao de um ambiente para minimizar o risco de indisponibilidade do sistema aos seus usurios. Muitas empresas preferem correr o risco de indisponibilidade do que pagar por essa duplicao.

1.7.3 Fase de design

Enquanto na fase de anlise vericamos o que dever ser feito, na fase de design precisamos denir como a soluo ser desenvolvida para atender s necessidades e expectativas do projeto. Ela deve caracterizar o sistema

34

Anlise e Design Orientados a Objetos

com base nos requisitos de tecnologia, selecionando a que melhor atende s necessidades do projeto. O design descreve a soluo minuciosamente, especicando detalhes da tecnologia selecionada e de que maneira ela ser utilizada. Na abordagem orientada a objetos com UML, devemos produzir nessa fase todas as especicaes tcnicas que sero utilizadas pelos desenvolvedores na construo do sistema. Essas especicaes tcnicas podem possuir vrios diagramas previstos na UML, sendo que diagramas de atividade, de classes e de sequncia geralmente so sucientes para produzir uma especicao com qualidade. A fase de design deve atender aos seguintes objetivos: resolver o problema de negcio; verificar elementos de suporte que faro o sistema funcionar; definir uma estratgia para implementao do sistema; produzir especificaes detalhadas do sistema; produzir casos de teste. Na fase de design, o modelo de classes inicial desenvolvido na fase de anlise deve ser especicado com grande nvel de detalhes. Tambm deve ser produzido um detalhamento completo da soluo (Arquitetura da soluo, banco de dados, linguagem de programao, padres de design utilizados etc.). Como produtos dessa fase podemos ter tambm diagramas de sequncia e colaborao no nvel de projeto, diagramas de estado, quando necessrio, diagramas de componente e diagramas de distribuio. Veremos no prximo captulo como esses subprocessos apresentados se enquadram dentro de algumas metodologias de desenvolvimento de sistemas utilizadas pelo mercado.