Apostila de UML

Verso: 2.
www.marcelosincic.com.br
Pgina 1 de 35
Ol, Criei estas apostilas a mais de 5 anos e atualizei uma srie delas com alguns dados adicionais. Muitas partes desta apostila est desatualizada, mas servir para quem quer tirar uma dvida ou aprender sobre .Net e as outras tecnologias.
Perfil Microsoft: https://www.mcpvirtualbusinesscard.com/VBCServer/msincic/profile Marcelo Sincic trabalha com informtica desde 1988. Durante anos trabalhou com desenvolvimento (iniciando com Dbase III e Clipper S'87) e com redes (Novell 2.0 e Lantastic). Hoje atua como consultor e instrutor para diversos parceiros e clientes Microsoft. Recebeu em abril de 2009 o prmio Latin American MCT Awards no MCT Summit 2009, um prmio entregue a apenas 5 instrutores de toda a Amrica Latina (http://www.marcelosincic.eti.br/Blog/post/Microsoft-MCT-Awards-AmericaLatina.aspx). Recebeu em setembro de 2009 o prmio IT HERO da equipe Microsoft Technet Brasil em reconhecimento a projeto desenvolvido (http://www.marcelosincic.eti.br/Blog/post/IT-Hero-Microsoft-TechNet.aspx). Em Novembro de 2009 recebeu novamente um premio do programa IT Hero agora na categoria de especialistas (http://www.marcelosincic.eti.br/Blog/post/TechNet-IT-Hero-Especialista-Selecionado-o-nosso-projeto-de-OCS2007.aspx). Acumula por 5 vezes certificaes com o ttulo Charter Member, indicando estar entre os primeiros do mundo a se certificarem profissionalmente em Windows 2008 e Windows 7.
Possui diversas certificaes oficiais de TI: MCITP - Microsoft Certified IT Professional Database Administrator SQL Server 2008 MCITP - Microsoft Certified IT Professional Database Administrator SQL Server 2005 MCITP - Microsoft Certified IT Professional Windows Server 2008 Admin MCITP - Microsoft Certified IT Professional Enterprise Administrator Windows 7 Charter Member MCITP - Microsoft Certified IT Professional Enterprise Support Technical MCPD - Microsoft Certified Professional Developer: Web Applications MCTS - Microsoft Certified Technology Specialist: Windows 7 Charter Member MCTS - Microsoft Certified Technology Specialist: Windows Mobile 6. Charter Member MCTS - Microsoft Certified Technology Specialist: Windows 2008 Active Directory Charter Member MCTS - Microsoft Certified Technology Specialist: Windows 2008 Networking Charter Member MCTS - Microsoft Certified Technology Specialist: System Center Configuration Manager MCTS - Microsoft Certified Technology Specialist: System Center Operations Manager MCTS - Microsoft Certified Technology Specialist: Exchange 2007 MCTS - Microsoft Certified Technology Specialist: Windows Sharepoint Services 3.0 MCTS - Microsoft Certified Technology Specialist: SQL Server 2008 MCTS - Microsoft Certified Technology Specialist: .NET Framework 3.5, ASP.NET Applications MCTS - Microsoft Certified Technology Specialist: SQL Server 2005 MCTS - Microsoft Certified Technology Specialist: Windows Vista MCTS - Microsoft Certified Technology Specialist: .NET Famework 2.0 MCDBA Microsoft Certified Database Administrator (SQL Server 2000/OLAP/BI) MCAD Microsoft Certified Application Developer .NET MCSA 2000 Microsoft Certified System Administrator Windows 2000 MCSA 2003 Microsoft Certified System Administrator Windows 2003 Microsoft Small and Medium Business Specialist MCP Visual Basic e ASP MCT Microsoft Certified Trainer SUN Java Trainer Java Core Trainer Approved IBM Certified System Administrator Lotus Domino 6.0/6.5
Reproduo e distribuio livre
Verso: 2.0
Pgina 2 de 35
Introduo ____________________________________________________ 4 1.1 Metodologias Para Desenvolvimento de Solues _______________ 4 1.2 Introduo a MSF / RUP _____________________________________ 4 1.2.1 Modelo de Times ________________________________________ 5 1.2.2 Modelo de Processos _____________________________________ 6 1.2.3 Gerenciamento de Riscos _________________________________ 7 1.2.4 Gerenciamento de Projetos ________________________________ 7 1.2.5 Documentao __________________________________________ 8
Viso / Escopo ________________________________________________ 9 2.1 Introduo ________________________________________________ 9 2.2 Tcnicas de Anlise ________________________________________ 9 2.2.1 Identificao de Escopo __________________________________ 10 2.3 2.4 Use Cases e Cenrios ______________________________________ 10 Refinamento e Fechamento _________________________________ 13 Introduo a Fase de Planejamento __________________________ 14 Pesquisa _________________________________________________ 14
Planejamento Modelo Conceitual ______________________________ 14 3.1 3.2
3.3 Anlise __________________________________________________ 14 3.3.1 Arquitetura da Aplicao _________________________________ 15 3.4 4 4.1 Otimizao _______________________________________________ 16 Introduo _______________________________________________ 16 Planejamento Modelo Lgico __________________________________ 16 4.2 Anlise __________________________________________________ 17 4.2.1 Tecnologias Candidatas __________________________________ 17 4.2.2 Definio de Atributos e Propriedades_______________________ 17 4.2.3 Definio de Multiplicidade e Relacionamento ________________ 18 4.2.4 Diagrama de Seqncia __________________________________ 19 4.2.5 Diagrama de Dados _____________________________________ 20 4.2.6 Design de Alto Nvel _____________________________________ 21 4.3 5 5.1 5.2 Otimizao _______________________________________________ 22 Introduo _______________________________________________ 23 Pesquisa _________________________________________________ 23 Planejamento Modelo Fsico __________________________________ 23
5.3 Anlise __________________________________________________ 24 5.3.1 Diagramas de Classe e Seqncia Revisados ________________ 24 5.3.2 Diagrama de Database Revisada __________________________ 25 5.3.3 Diagramas de Topologia e Componentizao _________________ 26 5.4 Racionalizao ____________________________________________ 27
Verso: 2.0
Pgina 3 de 35
5.5 5.6 6 6.1 6.2 6.3 7 7.1 7.2 7.3 8 8.1 8.2 8.3
Modelo de Implementao e Programao ____________________ 29 Otimizao _______________________________________________ 30 Introduo _______________________________________________ 30 Provas de Conceito ________________________________________ 31 Verses Internas (internal releases) __________________________ 31 Introduo _______________________________________________ 32 Convergncia de Bugs e Zero Bounce ________________________ 32 Verses Candidatas _______________________________________ 33 Introduo _______________________________________________ 34 Implantao de Tecnologias ________________________________ 34 Transferncia de Comando _________________________________ 34
Desenvolvimento _____________________________________________ 30
Estabilizao / Testes __________________________________________ 32
Entrega ______________________________________________________ 33
Verso: 2.0
Pgina 4 de 35
1 Introduo
1.1 Metodologias Para Desenvolvimento de Solues
Desde o inicio dos processos de desenvolvimento de software, ainda com os Mainframes, j existiam metodologias para anlise e desenvolvimento de software. Estas metodologias no especificam a tecnologia e sim modelos administrativos, documentais e organizacionais. Abrangendo desde a concepo at a entrega final da soluo, metodologias baseadas no modelo UML hoje se tornaram o padro entre as empresas e profissionais de informtica. At a dcada de 80 modelos baseados em linguagens eram os mais utilizados o que muitas vezes dificultava a migrao de uma aplicao entre diferentes linguagens e sistemas operacionais. Em meados dos anos 90, trs grandes pensadores da chamada engenharia de software, Jacobson, Booch e Rumbaugh, criaram o modelo Unified Modeling Language que conhecemos e nos referimos com o UML. Este padro de engenharia foi amplamente aceito por utilizar notao grfica e modelos de processos completos e versteis. Inicialmente a empresa Rational (hoje parte da IBM) criou junto com os trs criadores do UML a ferramenta chamada de Rose. Com a facilidade de um modelo para solues padronizado e uma ferramenta visual bem elaborada, empresas como Digital, HP, Unisys, IBM, Microsoft, Xerox entre outras, adotaram o UML em seus processos internos de desenvolvimento. Hoje as principais ferramentas UML so o XDE da Rational, Visio da Microsoft e Together da Borland. Mas engana-se quem ainda segue o principio Ivonsaf (Irresistvel VONtade de SAir Fazendo) de que apenas conhecer UML e criando os modelos grficos por ele definido o software ser um sucesso. necessrio conhecer todo o processo envolvido na criao da soluo proposta. Uma pesquisa realizada em 2000 pela Standish Group International em entrevista a mais de 30.000 profissionais de TI resultou na estatstica abaixo: Falharam (23%) Desafiadores (49%) Sucesso (28%) Porque isto acontece? Os motivos listados foram falta de comunicao dentro da equipe, m interpretao das necessidades do usurio, falta de recursos (dinheiro, pessoal e equipamentos), foco em tecnologia e no nos negcios e processos inflexveis. Como o UML apenas abrange uma notao padronizada para as solues, surgiram metodologias que complementassem esta notao por incluir gerenciamento de processos, riscos, documentao e equipes. Como exemplo temos o modelo RUP (Rational Unified Process), o MSF (Microsoft Solutions Framework) e o PMI (Project Management Institute).
1.2 Introduo a MSF / RUP

O Microsoft Solutions Framework baseado em UML e no RUP da Rational, lanado como produto em 93. Seu surgimento foi ocasionado por um levantamento interno realizado por ex-funcionrios da Anderson Consulting que haviam sido contratados pela Microsoft para unificarem os processos de desenvolvimentos dos diversos times existentes. Notou-se que UML era utilizado por todas as equipes e que os modelos administrativos e gerenciais eram similares aos utilizados pela Rational (RUP). Documentando estes processos, o MSF nos permite controlar e racionalizar uma soluo. Utilizamos o MSF como base por ser o modelo utilizado em todo o processo de desenvolvimento com .NET.
www.marcelosincic.com.br Reproduo e distribuio livre
Verso: 2.0
Pgina 5 de 35
Atualmente o modelo MSF est na verso 3.0 e formado por cinco principais conceitos: Modelo de Times Modelo de Processo Gerenciamento de Riscos Gerenciamento de Projetos Documentao 1.2.1 Modelo de Times Os envolvidos no desenvolvimento da soluo foram separados em 6 times: Gerente de Produto (Product Manager) o responsvel pela comunicao com o usurio detentor dos recursos (Stakeholder). Este profissional possui um conhecimento bsico de informtica, uma vez que a sua principal funo ser conhecer o cliente e vender o produto. Gerente de Projeto (Project Manager) Gerencia recursos como dinheiro, pessoal, equipamentos e prazos do projeto. No o chefe nem o encarregado tcnico do projeto, portanto seu conhecimento tecnolgico precisa ser amplo e no especfico. Faz parte de sua equipe os analistas de sistemas e engenheiros de software. A estes cabe definir as tecnologias, mas no implant-las. Desenvolvedores (Developers) So os tcnicos envolvidos no projeto, desde o programador at o pessoal de segurana e sistemas operacionais. Estes possuem alto nvel tcnico especializado pois sero os responsveis pela implementao, implantao e codificao. Testes (Testers) Equipe que ir conduzir os testes da soluo. Em alguns tipos de testes, por exemplo de segurana, necessitam ter alto nvel tcnico, enquanto em outros testes, por exemplo testes de navegao, o nvel tcnico exigido menor. Usabilidades (User Testers) Ocupam um importante papel por serem conhecedores da soluo e no de tecnologia. Caber a estes avaliar se as necessidades e expectativas do cliente e usurios finais foram atingidas. Gerencia de Produo/Operao (Release Manager) Equipe de suporte e operao, responsveis pela implantao e suporte quando a soluo estiver em produo. A vantagem do modelo de equipes bvia por definir responsabilidades o que evita conflitos. O modelo de equipe tambm prega os seguintes conceitos: Viso compartilhada Cada membro da equipe precisa conhecer o objetivo do projeto, o seu papel e os prazos envolvidos. Quando os membros da equipe no se sentem partes do projeto perdem a iniciativa, o que ocasiona perda de qualidade. Foco em Negcios A maior parte dos processos que fracassam tiveram seu foco em tecnologia e no no negcio. Projetos que visam explorar uma nova tecnologia ou visto como oportunidade para aprender um novo produto, tende a estar entre os 77% dos projetos ineficientes. Tenha em mente que trabalhamos em organizaes comerciais que visam lucro e no para as empresas de telecomunicaes e software. Isto exige alta disciplina, mas resulta em projetos lucrativos.
Verso: 2.0
Pgina 6 de 35
gil e flexvel Nos anos em que os Mainframes e CPDs eram reinantes, a mudana de uma pequena frase em um documento gerado pelo sistema provocava uma guerra entre tcnicos e usurios. Hoje em dia a realidade totalmente diferente, o poder de processamento dobra a cada 18 meses (regra de Moore) e as organizaes se reestruturam a cada trs anos, criando mudanas significativas nos processos e sistemas de uma empresa. Comunicao Uma equipe que tem medo de se expressar uma equipe de zumbis. Esta frase define bem o que acontece quando os gerentes e lderes no permitem a liberdade de pensamento. Todos os integrantes da equipe precisam se sentir vontade ao dar opinies, sem medo de serem punidos, repreendidos ou ridicularizados. Fornecer meios de ouvir os membros da equipe, mesmo que anonimamente, aumenta a eficincia por ouvir e motivar a base de produo. Empresas como Alcoa, Ita, Randon e muitas outras montaram sistemas de premiao a boas idias.
1.2.2 Modelo de Processos Dividir o projeto em fases utilizado nos modelos MSF 3.0, PMI e RUP. Apesar da separao em fases, todo o modelo baseado em Spiral e Waterfall. O modelo Espiral define que o projeto pode ser particionado, e que cada funcionalidade do projeto pode ter seu desenvolvimento iniciado assim que suas documentaes estiverem prontas. Por exemplo, em um sistema para locao de imveis podemos dividir o projeto em cadastro de imveis, cadastro de clientes e vendas. Ao terminar a documentao do cadastro de imveis j iniciamos o desenvolvimento enquanto documentamos o cadastro de clientes. O modelo Waterfall baseado em millestones ou marcos. Estes marcos definem onde cada uma das cinco fases principais ou suas sub-fases comeam e terminam. Os marcos tem como atrativo deixar as equipes sincronizadas Com a juno dos dois modelos podemos modularizar um projeto (espiral), definindo quando cada mdulo considerado documentado (marco) para o inicio do desenvolvimento. As cinco fases do processo so: Viso (Envisioning) Nesta fase conduzimos as entrevistas e criamos os use-cases que so as definies do que a soluo far e o que no far. A isto chamamos de Escopo (scope). Planejamento (Planning) Dividida em trs sub-fases, todas as documentaes do sistema so geradas nesta fase. considerada uma fase crtica, pois um erro de planejamento pode resultar na reescrita de tudo o que j estiver pronto. Desenvolvimento (Developing) Inclui desde a codificao at testes com sistemas operacionais e tecnologias. Tipicamente a maior fase do projeto. Estabilizao (Estabilizing) Testes com usurios internos e externos (beta users) so conduzidos de forma sistemtica at conseguir se chegar ao chamado Golden Release, verso final do produto para venda ou implantao. Entrega (Deployment) ltima fase mas no menos importante, quando criamos a poltica e efetiva implantao do
Verso: 2.0
Pgina 7 de 35
projeto. Nesta fase se torna difcil qualquer correo no sistema, uma vez que as outras equipes j foram desmontadas. 1.2.3 Gerenciamento de Riscos O que um risco? Riscos so quaisquer fatores que possam causar dificuldades. Os riscos no se resumem a tecnologia. Podem ser organizacionais, administrativos, financeiros, pessoais, etc. Qualquer projeto, desde o menor at os faranicos, possui uma lista de fatores que podero naufragar o projeto. Alguns projetos possuem poucos riscos, mas a maior parte possui tantos riscos que precisamos formular quais so mais importantes. Para categorizar riscos precisamos da participao de todos os membros de todas as equipes, uma vez que para o gerente de produto os riscos envolvero o cliente, para os desenvolvedores riscos tcnicos e para a equipe de usabilidade os costumes do usurio. Utilizando um modelo bsico de riscos, veja o exemplo abaixo:
rea Risco G.Proj Oramento enxuto, prazo curto Desen Tecnologia rev cente, documentao escassa G.Pro Difcil acesso ao d dono da empresa Probabilidad Impact e o 4 5 3 3 Exposi o 20 9 Mitigao Contratar profissionais com bom gabarito e skill tcnico Antes da escolha do wi-fi verificar documentaes disponiveis Marcar as reunies e apresentaes do sistema com antecedncia Contingncia Tercerizao de tcnicos na implantao Contratao de um profissional experiente na tecnologia Definir um substituto com poder de deciso equivalente
Neste exemplo notamos as colunas probabilidade que indica a espera do risco, o impacto caso a situao se confirme e a exposio que o resultado da multiplicao dos dois primeiros. Esta coluna essencial para definio dos Top 10. Mitigao so recursos que podem ser usados previamente a fim de evitar a situao, enquanto contingncia um recurso que no queremos utilizar por qualquer motivo que seja, mas ter que ser utilizada em ultimo caso. Nesta planilha no consta a coluna Disparo, permitindo definir quando a contingncia ser necessria. 1.2.4 Gerenciamento de Projetos Projetos possuem trs principais sustentadores, chamados de trade: Recursos Itens necessrios para o projeto, destacando-se pessoal, dinheiro e equipamentos. Prazos Prazos mximo do projeto e de cada uma das suas fases Funcionalidades As tarefas que o usurio definiu como sendo parte do sistema O bom gerenciamento da trade conseguir definir qual das trs mais importante, qual aceitvel e, por conseguinte, a que ajustvel. Veja os exemplos abaixo:
Fix o Prazo No pode ser alterado, entrega at dia 01/10
Aceitv el
Ajustv el
Verso: 2.0
Pgina 8 de 35
Recursos Equipe j existente com 5 pessoas. No temos autorizao para aumento da equipe Funcionalidade Os mdulos 1 a 5 so prioritrios. Os mdulos restantes podero ser desenvolvidos em outra ocasio
O exemplo acima demonstra que o prazo inegocivel, recursos foram aceitos como esto e que as funcionalidades esto comprometidas. Fica claro ao cliente que para fazer no prazo especificado com o pessoal fornecido no nos comprometemos com todas as funcionalidades desejadas. Cabe ao gerente de projeto definir um cronograma com todos os marcos e com este cronograma em mos cuidar de que os prazos no sejam ultrapassados. O mesmo deve ser feito utilizando uma lista de equipamentos e pessoas para controle. 1.2.5 Documentao A documentao essencial para o desenvolvimento e tambm para o cliente. Todos os papeis gerados durante o planejamento deve ser anexado ao documento inicial de Viso/Escopo formando uma pasta para referncia. Tambm durante o projeto so gerados documentos de suporte a usurio, chamados internacionalmente de KB (Knowledge Base), bem como manuais, resoluo de problemas comuns, etc. Um sistema bem documentado tambm incluir padres de desenvolvimento e codificao, por exemplo, nomenclatura de objetos, database e servidores. NOTA: Os documentos gerados em um projeto sero demonstrados ao longo do curso.
Verso: 2.0
Pgina 9 de 35
2 Viso / Escopo
2.1 Introduo
O inicio de um projeto marcado por um financiador (stakeholder) ou cliente que ao ter uma idia sugere a criao do sistema. A partir deste momento passamos a ter o envolvimento de pelo menos um representante de cada equipes para definio do documento de viso. Este documento define o escopo do projeto, que indica ao cliente as funes que sero implementadas e as que no sero. Se ao definir um escopo prometermos mais do que podemos fazer com o dinheiro e prazos definidos, o projeto ir naufragar. No necessrio neste momento definir tecnologias, mas ser necessrio pensar nelas, afinal, no podemos prometer algo que a atual tecnologia ou os custos impossibilitem.
2.2 Tcnicas de Anlise

So diversos os mtodos de anlise que podemos utilizar, mas precisamos ter cuidado com o tipo de pblico, nvel de responsabilidade e nvel hierrquico. Veja abaixo alguns exemplos:
Mtodo Shadow (sombra) Seguir o usurio final,anotando atividades do seu diaa-dia Pblico -Baixo conhecime nto -Baixo nvel de deciso Entrevista -Alto Mtodo comumente conhecime utilizado por uma nto conversa informal -Alto nvel de deciso Grupos (JADE) -Mdio Reunir um grupo de conhecime pessoas que estejam nto envolvidas -Mdo nvel de deciso Pesquisa -Mdio Elaborar conhecime questionrios a serem nto preenchidos -Baixo nvel de deciso Manuais (outputs) No se Utiliza-se o manual aplica de operaes, retornos de dados ou impresses Prottipo No se Criar um modelo para aplica ser testado por tcnicos ou usurios Vantagens Fornece dados importantes de como a tarefa executada, quem a executa, em que ordem e quando. Desvantagens Raramente consegue-se saber porque determinadas tarefas so executadas.
Permite conhecer os motivos que levam ao processo, quem o executa e porque, bem como detalhes importantes sobre a empresa e o negcio. Levanta-se o processo dos diferentes pontos de vista dentro da organizao.
Demanda muito tempo, muitos detalhes ficam ocultos. No conseguimos enxergar dificuldades operacionais. Demanda muito tempo, e muitas vezes desenvolve-se como uma discusso entre reas, onde a mais forte tenta predominar. Divagao freqente, processos mal-descritos, tempo de retorno dos questionrios altamente varivel, falta de confiabilidade. Acomodao nos mesmos moldes, falta de criatividade e soluo que apenas ficou mais atraente. Exige que um sistema Delta seja criado, o que pode demandar muito tempo. Informaes desencontradas em cada nvel de usurio.
Fornece um amplo ponto de vista, annimo e no compromete cargos de alto nvel, no tomando tempo desnecessrio. Dados em tempo real e oficiais da empresa, altamente confiveis. o melhor mtodo quando da migrao de sistemas legado. Quando um novo projeto na organizao, permite avaliar aceitao e funcionamento.
Verso: 2.0
Pgina 10 de 35
2.2.1 Identificao de Escopo Aps as anlises estarem prontas, precisa-se definir o escopo, ou os requisitos do sistema. Esses podem ser divididos basicamente em quatro tipos: Funcionais Definem o que o sistema dever fazer, como fazer e quando o faz. Por exemplo, o sistema dever ser capaz de registrar os produtos, estoque e as vendas, bem como gerar histricos e relatrios. Dados Define a estrutura esttica, os dados que devero ser guardados. Por exemplo, o produto dever conter cdigo, descrio, preo, estoque mnimo e estoque atual. Interface Envolve o usurio na operao, pode ser uma tela de input ou um relatrio. Por exemplo, a recepcionista deve preencher o RG, nome e pessoa visitada, digitando logo em seguida o nmero do crach fornecido. No-funcional Identifica partes da soluo que no so diretamente ligadas a ela. Podem ser requisitos de segurana, sistema operacional, meio de acesso, etc. Por exemplo, o sistema dever ser desenvolvido em C# executado no Windows 2003 e com chave de criptografia de 128 bits modelo RSA.
2.3 Use Cases e Cenrios

Use cases, ou casos de uso, identificam a ordem em que os eventos acontecem, quem o executa, quem ou o que est envolvido e como ser executado. Os UC surgem quando se refina as entrevistas tornando-as lgicas. Um UC define funcionalidades do sistema, enquanto os cenrios definem variaes desta funcionalidade. Por exemplo, imaginando um sistema de controle em um restaurante podemos definir o primeiro UC como sendo o atendimento do garon:
Cenrio UC 1.1 Cliente solicita produto Tarefas envolvidas 1. Garom anota o pedido 2. Destaca a via da cozinha e leva ao escaninho 3. Ajudante da cozinha pega o formulrio 4. Cozinha prepara o pedido 5. Garom entrega o pedido na mesa 6. Cozinha entrega o formulrio ao caixa 7. Caixa coloca o formulrio na colmia 1. Garom passa o numero da mesa ao caixa 2. Caixa retira os formulrios da colmia 3. Soma os pedidos 4. Digita os dados no sistema fiscal 5. Imprime a conta 6. Garom leva a conta ao cliente 1. Garom entrega o dinheiro ao caixa 2. Caixa d baixa na conta e anota nos pedidos 3. Caixa coloca os pedidos no escaninho de arquivo 4. Caixa guarda o dinheiro 5. Se houver troco o caixa entrega ao garom 6. Garom entrega o troco ao cliente, se houver
UC 1.2 Cliente solicita a conta
UC 1.3 Cliente paga em dinheiro
Como pode ser visto neste exemplo, criamos um UC com trs diferentes cenrios. Tambm possvel definir os cenrios de forma grfica. A primeira delas o diagrama de atividade, tambm chamado de fluxograma:
Verso: 2.0
Pgina 11 de 35
Estado Inicial Inicio da atividade

G arom entrega o dinheiro ao caixa
C aixa d baixo na conta e anota nos pedidos
Estado Final Final da atividade
State1
C aixa coloca os form ularios no arquivo
Estado Identifica cada interao
C aixa guarda o dinheiro
Deciso Variaes que podem ocorrer

T em troco ?
[S im ] [N o] C aixa entrega troco ao garom
G arom entrega o troco ao cliente
Os use cases tambm podem ser representados graficamente, mas neste caso eles exemplificam a relao entre os diferentes mdulos e interaes entre o sistema:
Verso: 2.0
Pgina 12 de 35
uses A n o ta r P e d id o e x te n d s G a r o m E x e c u ta r P e d id o C o z in h a uses
A c to r 1
Ator Identifica quem interaje com cada funcionalidade, seja uma pessoa ou um sistema
U seC ase1
S o m a r P e d id o s uses e x te n d s uses E m itir N o ta C a ix a e x te n d s uses uses
Use Case Diferentes funcionalidades

uses
Use Identifica quem utiliza ou interage com a funcionalidade

e x te n d s
uses
uses S is te m a F is c a l D a r B a ix a
Extend Identifica que determinada funcionalidade amplia outra, sem necessariamente estar interligada
Este diagrama mostra como utilizar os UCs grficos, e como estes podem servir mais tarde para identificar as diferentes classes que o sistema vai conter. Veremos no mdulo seguinte que os UCs sero refinados na etapa de Planejamento. Vamos entender melhor como utilizar os UCs grficos. Ao ler uma entrevista, um UCs descritivo ou um diagrama de atividades, identifique os atores, objetos e aes especificadas. Atores podem ser facilmente identificados porque manipulam os objetos. Objetos so os itens que foram manipulados. Por fim, aes so verbos, as manipulaes. Veja os exemplos abaixo:
Atividade Garom anota o pedido Caixa lana pedidos no sistema Cozinha executa o pedido Ator Garom Caixa Sistema Cozinha Objeto Pedido Pedido Pedido Ao Anotar Lanar Executar
Esta lista ainda no definitiva, ela ser revista na fase de planejamento. Chamamos esta lista de Candidatos. Alem do UML outro modelo muito utilizado para definir UCs chamado de Modelagem dos Papeis dos Objetos (ORM Object Role Modeling). O ORM descreve os UCs de forma analtica, permitindo um entendimento dos cases por no utilizar desenhos tcnicos como o UML. Por outro lado, o ORM gera muito mais papeis e documentaes do que o UML, pois com um grfico de UCs e mais trs grficos de atividade que podem estar em uma nica folha, conseguimos representar as trs operaes analisadas. Com ORM teriamos um modelo descritivo em linguagem natural. Outra soluo muito adotada utilizar o ORM inicialmente para descrever as atividades e mais tarde fazer os diagramas grficos de UML, j como refinamento.
Verso: 2.0
Pgina 13 de 35
2.4 Refinamento e Fechamento

Refinamento quando pegamos os UCs e utilizando o mtodo Walk-Throggle (andar sobre ele) verificamos se as informaes esto consistentes. Isto feito por se colocar no lugar de um usurio e seguindo os diagramas de atividade simular a tarefa sendo executada. Com este testes podemos identificar os chamados objetos ocultos. Com a descoberta destes objetos, refazemos os modelos. Outra importante funo do refinamento conseguir mapear o Estado Atual e o Estado Futuro. Estes consistem em descrever como atualmente o processo executado e o segundo modelo como ser executado com o novo sistema. Um exemplo do UCs citado anteriormente e o estado futuro seria:
uses A n o ta r P e d id o
G a r o m
Im p rim ir P e d id o
uses uses
uses
C o z in h a
uses
F e c h a r p e d id o e x te n d s uses
S is te m a R e s ta u ra n te
E m itir N o ta
uses
D a r B a ix a C a ix a
Cenrio UC 1.1 Cliente solicita produto
UC 1.2 Cliente solicita a conta
Tarefas envolvidas 1. Garom anota o pedido no Pocket PC 2. A impressora da cozinha automaticamente emite um ticket 3. Ajudante da cozinha pega o ticket 4. Cozinha prepara o pedido 5. Garom entrega o pedido na mesa 1. Garom digita o fechamento no Pocket PC 2. Garom recebe o valor do cliente 3. A impressora do caixa emite o recibo 4. Garom entrega o dinheiro ao caixa 5. Caixa da baixa no sistema 6. Caixa guarda o dinheiro 7. Se houver troco o caixa entrega ao garom 8. Garom entrega o troco ao cliente
Verso: 2.0
Pgina 14 de 35
3 Planejamento Modelo Conceitual

3.1 Introduo a Fase de Planejamento
A fase de planejamento se destaca em um projeto por ser considerada o cerne de uma soluo. Imagine um engenheiro desenhando um edifcio de 6 andares e esquecer de colocar as tubulaes de telefone. Este engenheiro pode contar com a sorte de ter um mestre de obras consciente que lhe avise da falta e seja corrigido, mas caso isto no acontea os moradores iro ficar insatisfeitos e com certeza resultar em prejuzos a construtora. Similarmente, um projeto de sistema tem a mesma fragilidade. Se a fase de planejamento for mal feita, provavelmente os programadores no enxergaram isto por no conhecerem diretamente o usurio final. Quando o cliente receber o sistema pronto, este notar dificuldades e assim como aquele morador insatisfeito, assim ficar seu cliente. A fase planejamento como j abordado anteriormente, divida em trs fases (conceitual, lgica e fsica) e formulada de forma espiral, ou seja, dividimos o projeto em pores, os use cases, e executamos o planejamento e desenvolvimento conforme o fechamento de cada use case.
3.2 Pesquisa
Nesta etapa os analistas de sistemas com um nvel tcnico mais alto e que no necessariamente estiveram envolvidos na fase de viso, quando as entrevistas foram realizadas, iro analisar os UCs e fazer o processo chamado de restate ou re-estado. Isto significa analisar as atividades de forma sistmica, ou seja, como um programa de computador, uma vez que at este momento os use cases e cenrios foram sempre analisados do ponto de vista do usurio. Com este mtodo de pesquisa ser possvel contestar, sugerir incluses ou excluses de atividades. Utilizamos o termo sugerir porque ao propor alteraes j com os UCs montados precisamos que os analistas que originalmente os montaram aprovem as alteraes e que o cliente tambm o faa, uma vez que no final da fase de viso e escopo foi obtido um aval por parte do cliente. Estas alteraes caso impliquem em extenso do prazo ou dos gastos tem que ser aprovada novamente. Nesta fase tambm levantado o User Profile, ou perfil do usurio, que a identidade tcnica e educacional de quem ir estar operando o sistema. Por exemplo, se o perfil for escritrio podemos desenvolver interfaces mais ricas, enquanto o perfil fabril exige interfaces simples, muitas vezes sem uso de mouse.
3.3 Anlise
Na fase de anlise dos use cases iremos identificar os objetos principais, atores e aes criando um documento que sintetize o que cada ator manipula, entender requisitos tcnicos como por exemplo, segurana, escalabilidade, etc. Exemplificando um modelo re-analisado e sintetizados temos:
Ator Garom Atividades Logar no Pocket PC Cadastrar itens na mesa Consultar a conta da mesa Fechar a conta da mesa Informar a forma de pagamento Imprimir pedido Logar no sistema
Cozinha Caixa
Verso: 2.0
Pgina 15 de 35
Como visto neste documento, a funo Logar no sistema e Informar a forma de pagamento no estavam listadas entre as atividades anteriormente levantadas nos use cases originais. Na anlise conceitual do sistema concentra-se algumas das mais crticas decises do projeto, que envolvem a escolha da arquitetura da aplicao. 3.3.1 Arquitetura da Aplicao Para entender o que representa a arquitetura da aplicao precisamos entender os modelos de desenvolvimento em camadas e servios. Desenvolvimento em servios envolve separar os diferentes atores, objetos e aes conforme a funo que desempenham. Os servios so: Apresentao Estes envolvem a UI (User Interface) incluindo formulrios, relatrios, pginas web e quaisquer outras formas de entrada de dados. Negcios Encapsulam, ou controlam, as regras do sistema. Dados Define basicamente a persistncia de dados, mas muitas vezes pode representar dados dinmicos e temporrios. A planilha abaixo demonstra como o sistema visto anteriormente seria classificado:
Componente Garom Caixa Login ValidaLogin Vendas Produtos Pedidos Cozinha Conta Recebimento Recibo Funo Dados dos garons (login) Dados dos caixas (login) Tela de logon Verifica se os dados esto corretos Tela de insero para os pedidos Dados de produtos para venda Dados dos pedidos Imprime os pedidos na cozinha Soma os pedidos Cadastra as formas de pagamento Imprime o recibo Apresentao Negcios Dados
Consultar a conta da mesa Imprimir o cupom fiscal Processar a baixa do pedido
Este exemplo demonstra dois conceitos importantes. O primeiro notamos ao ver que a lista de componentes inclu aqueles refinados anteriormente e que no constavam no UC por serem ocultos, como por exemplo, o componente recebimento e conta. O segundo conceito a separao de servios. Os componentes de apresentao se transformaram em formulrios, pginas web e relatrios. Quanto aos componentes de negcios sero implementados como DLLs e os componentes de dados se tornam tabelas em banco de dados, XML ou outro sistema de persistncia. Como pode ser notado, os servios so importantes para definir em que linguagens, sistema ou servidor ser implementado cada uma das diferentes partes que compe a soluo. Agora vamos entender o modelo de camadas. Uma aplicao chamada de Monoltica quando seus diferentes servios esto todos vinculados a um nico assemblie (programa que pode ser dll, exe, com, etc.). Por exemplo, imagine o programa desenvolvido pela Receita Federal para elaborao do imposto de renda, desenvolvido em Delphi em um nico executvel, para facilitar a distribuio. O
Verso: 2.0
Pgina 16 de 35
fato de um sistema ser monoltico no quer dizer que no tenha o conceito de servios, mas sim que ele foi compilado como uma nica parte. Podemos desenvolver sistema baseados em servios mas implementado em um nico assemblie, como na situao da Receita Federal. Quando um sistema desenvolvido no modelo de servios implementado em diferentes assemblies chamamos este sistema de multi-tier ou layered (multicamadas). Outro modelo muito utilizado o modelo Client-Server (cliente-servidor) onde temos a camada de apresentao em um programa desenvolvido em Visual Basic, por exemplo, enquanto os dados esto em um banco de dados relacional como o MS-SQL Server ou Oracle. A escolha do modelo depende muito da aplicao e est vinculado a alguns fatores:
Modelo Client-Server O software cliente instalado na maquina do cliente ou em um servidor compartilhado e os dados em um servidor DBMS. Vantagens -Acesso a dados em uma nica fonte, dados centralizados -Baixo processamento do cliente -Fcil distribuio -Fcil desenvolvimento -Cada componente pode ser manipulado individualmente -Alta escalabilidade, por permitir que cada servidor leve sua prpria carga -Manuteno simplificada -O cliente s necessita de conexo no inicio e fim das operaes -Alta escalabilidade, pois os clientes no ficam conectados -Alta performance -Alta escalabilidade -Acesso a dados centralizado -Alta performance Desvantagens -Alta conectividade -Em caso de falta de comunicao todo a soluo ir parar -Dificil manuteno quando instalado nos clientes -Performance comprometida -Dificil distribuio, diferente em cada camada -Complexo desenvolvimento -Alta conectividade -Performance comprometida -O cliente no enxerga atualizaes real-time por outros clientes, ocorrendo conflitos constantes -Conplexo desenvolvimento -Complexo desenvolvimento -Alta conectividade
Multi-Tier / Layered Cada diferente parte do software est separada. Os servios de apresentao no cliente ou servidor compartilhado, os de negcios em um servidor de aplicao e os dados em um servidor DBMS. Stateless (Estado Cheio) Ao se conectar a aplicao o cliente recebe todos os dados e devolve ao finalizar as alteraes que houver efetuado.
Layered-Client-Server-Stateless Juno dos modelos, onde o cliente se conecta pede os dados necessrios na funo que ir executar, envia atualizaes e atualiza os dados localmente.
3.4 Otimizao
Neste ultimo esforo do planejamento conceitual quando validamos tudo o que foi analisado e pesquisado. Faa o caminho do usurio (walk-through) e verifique se compriu com os requisitos exigidos. Uma srie de perguntas pode ser feita para ajudar: O processo se tornou mais simples ? Est em conformidade com o perfil do usurio ? Melhorou a performance nas atividades ? Consigo apontar eficientemente ROI (retorno de investimento) ? Eliminei papeis e burocracias ? Estes exemplos so teis para ilustrar as diferentes questes que mostram se a sua soluo ou no vivel como est sendo proposta e se os recursos empregados iro valer a pena.
4 Planejamento Modelo Lgico

4.1 Introduo
No modelo lgico desenvolvemos a aplicao de forma prtica. nesta fase, to critica quanto a fase conceitual, que definimos bases de dados, classes e modelos. No agora que montamos as
Verso: 2.0
Pgina 17 de 35
tabelas em um DBMS, nem codificamos ou definimos a tecnologia fsica, mas criamos os parmetros tcnicos necessrios. Uma boa classificao para o lgico dizer que serve de ponte entre o modelo conceitual (ponto de vista do usurio) para o modelo fsico (ponto de vista dos tcnicos).
4.2 Anlise
Na fase de anlise iremos definir tecnologias candidatas, objetos, atributos, relacionamentos e sequencia de operaes. Esta fase a nica da fase lgica, seguida da otimizao, assim como no modelo conceitual. 4.2.1 Tecnologias Candidatas Iniciamos a fase lgica por escolher as tecnologias candidatas. Estas podem ser diversas, mas ao final do modelo fsico sero nomeadas. Alguns dos fatores so:
Tipo Requisito Possibilidade Custos Experincia ROI Maturidade Suporte Equipamentos Atuais Equipamentos Futuros Segurana Interoperabilidade Acesso a Dados Persistncia Servios de Sistema Ferramentas RAD Sistema Operacional Descrio As tecnologias existem e esto disponveis? O custo vivel? O mercado tem documentao e profissionais habilitados? O prazo de retorno de investimento aceitvel? A tecnologia est madura e estvel? Ao encontrar problemas, qual o tempo de soluo? Fornecem o hardware necessrio? A empresa tem os pr-requisitos para a nova tecnologia? A tecnologia tem criptografia, autenticao, autorizao e outros recursos? Consegue conversar com outros sistemas em modelos padronizados, como XML por exemplo? Fornece drivers para acesso simplificados que permitam acesso rpido e simples? Os dados guardados sero de rpido acesso e confiveis? Possui suporte a transaes atmicas, comunicao assncrona e outros? As ferramentas de desenvolvimento so usuais e simples? Permite criptografia de trfego, suporte a diferentes hardwares, etc? Candidatos C# VB.NET Java Microsoft Visual Studio 2003 Borland Jbuilder Microsoft Windows Server 2003 IBM WebSphere Handheld com Pocket PC 2003 para os garcons Palm com PalmOS 3.0 ou superior para os garons Pentium III com 256 MB para os caixas Impressora matricial de 40 colunas na cozinha Impressora trmica fiscal no caixa Microsoft SQL Server 2000 Oracle 8 ou superior
Negcios
Empresa
Tecnolgicas
Um exemplo de tecnologias candidatas poderia ser:

Requisito Linguagem de programao
Ferramenta RAD Sistema Operacional Equipamentos
Banco de Dados
4.2.2 Definio de Atributos e Propriedades Atributos so tipicamente caractersticas de um objeto de dados. Por exemplo, um carro possui os atributos marca, fabricante, numero de passageiros, cavalos de fora, etc.
Verso: 2.0
Pgina 18 de 35
Nesta fase pegamos os componentes anteriormente classificados e procuramos os atributos que so necessrios. Normalmente servios de apresentao no contem atributos, pois so estes componentes que recebem os dados do usurios para enviar aos componentes de negcios e dados. Uma propriedade tem um conceito mais amplo do que atributo, pois tambm define aes que cada objeto executa, os chamados mtodos. Estes mtodos so definidos em conformidade com o que Em nosso caso iremos definir as propriedades (atributos e mtodos) utilizando UML chamado de Diagrama de Classes, como exemplificado abaixo:
G a ro m +C od igo : sh o rt(id l) +N om e : ch ar(idl) -S e nh a : string (id l) P ed id o s + S eq ue ncia l : lon g(idl) + C o d ig o d o G a rom : sh ort(id l) + M esa : fixed (id l) + C o d ig o d o P ro du to : fixed (id l) + Q u an tid ad e : fixe d (idl) + D a ta e H o ra : string (id l) + In cluir P ed ido () P ro d u to s + C o d ig o : fixed (idl) + D e scricao : ch ar(idl) + P re co : lo ng (id l) + E sto qu e : lo ng (idl) + E sto qu e M inim o : lon g(id l) + In lcuir P ro du to () + A lte ra r P rod uto() + P ro du to s se m E stoq ue () V en d as + E n trar D ad os() C o zin h a + Im p rim ir P ed ido() C o n ta +N um ero d o R ecib o : lon g (idl) +S e qu en cial do P e did o : lo ng (idl) +V a lor T o ta l : lon g(idl) +S o m ar P e did os () +F e cha r C o n ta ()
Cada um dos smbolos ao lado indicam uma diferente classe. As classes possuem duas divises onde a diviso superior so os atributos e segunda parte com as operaes, ou mtodos. O + ao lado indica que a principio esto definidos como pblicos. O idl (intermediary definition language), um padro de dados universal.
C aixa + C od igo : sh ort(id l) + N om e : ch ar(idl) + S en h a : strin g(idl)
R e ce b im en to + S eq ue ncia l : lon g (id l) + N u m e ro do R e cibo : lo ng (idl) + T ipo d e P a ga m en to : fixed (idl) + V alo r : lon g (idl) + In clu ir R e ceb im en to () + C a lcular T roco ()
V alid aL o g in + C od igo : sh ort(id l) + S en h a : strin g(idl) + V alid ar L og in () L o g in + E ntrar D a do s()
R e c ib o + Im p rim ir re cib o()
No diagrama acima j temos uma viso de que atributos e operaes cada classe necessita, o que essencial para o restante das documentaes. Operaes com o sinal (+) indicam pblicas, o sinal () indica private e por fim o sinal (#) protected. 4.2.3 Definio de Multiplicidade e Relacionamento Relacionamento indica qual componente de sua soluo interage com as outras. Esta definio tambm inclui a multiplicidade. Multiplicidade o numero de ocorrncias includas de um objeto sobre o outro. Por exemplo, um pai pode ter vrios (tipicamente utilizamos n) filhos, enquanto um filho s pode ter um pai. Usamos os seguintes nomenclaturas:
Nomenclatura 1..1 1..* ou 1..n *..1 ou n..* *..* ou n..n 1..0 ou 0..1 Descrio Um para um Um para muitos Muitos para um Muitos para muitos Nenhum, ou um, para um Exemplo Cada pedido gera uma nota fiscal. Uma nota fiscal pode conter muitos produtos Diversos clientes so atendidos por um mesmo vendedor Diversos fornecedores podem vender diversos produtos, concorrentemente. Cliente pode ou no ter feito pedidos at o momento
Estes valores numricos representam a multiplicidade, mas tambm utilizamos alguns termos tcnicos para definir relacionamentos. Por exemplo, quando o item um para um utilizamos a expresso associao. Veja abaixo exemplos destes termos:
Nome Associao Smbolo UML
-End3 1
-End4 *
Exemplo Um vendedor pode atender diversos clientes
Generalizao
Podemos criar um objeto pessoa do qual tanto o caixa quanto o garom tem atributos comuns.
Verso: 2.0
Pgina 19 de 35
Realizao Dependncia
O objeto vendas realiza um objeto pedido. No Visio utilizamos o smbolo de dependncia com a descrio call. O objeto login depende dos objetos garom e caixa
Para exemplificar a multiplicidade e relacionamentos, veja o modelo abaixo:

P ro d u to s + C o d ig o : fix e d (id l) + D e s c r ic a o : c h a r ( id l) + P r e c o : lo n g ( id l) + E s to q u e : lo n g ( id l) + E s to q u e M in im o : lo n g ( id l) + In lc u ir P r o d u to ( ) + A lte r a r P r o d u to ( ) + P r o d u to s s e m E s to q u e ( ) * * P e d id o s + S e q u e n c ia l : lo n g (id l) + C o d ig o d o G a r o m : s h o r t( id l) + M e s a : fix e d ( id l) + C o d ig o d o P r o d u to : fix e d ( id l) + Q u a n tid a d e : fix e d ( id l) + D a ta e H o r a : s tr in g ( id l) + In c lu ir P e d id o ( ) * 1 P essoa + N o m e : c h a r ( id l) + S e n h a : s tr in g ( id l) C a ix a + C o d ig o : s h o r t( id l) + D a d o s C a ix a ( ) C o n ta + N u m e r o d o R e c ib o : lo n g ( id l) + S e q u e n c ia l d o P e d id o : lo n g ( id l) + V a lo r T o ta l : lo n g ( id l) + S o m a r P e d id o s ( ) + F e c h a r C o n ta ( ) 1 * R e c e b im e n t o V a lid a L o g in + C o d ig o : s h o r t( id l) + S e n h a : s tr in g ( id l) + V a lid a r L o g in ( ) + S e q u e n c ia l : lo n g (id l) + N u m e r o d o R e c ib o : lo n g ( id l) + T ip o d e P a g a m e n to : fix e d ( id l) + V a lo r : lo n g ( id l) + In c lu ir R e c e b im e n to ( ) + C a lc u la r T r o c o ( ) c a ll R e c ib o + Im p r im ir r e c ib o ( ) c a ll C o z in h a + Im p r im ir P e d id o ( )
V endas + E n tr a r D a d o s ( )
G ar o m + C o d ig o : s h o r t( id l) + D a d o s G a r o m () L o g in c a ll + E n tr a r D a d o s ( )
Neste modelo possvel enxergar os relacionamentos, dependncias e chamadas executadas a cada objeto, componente ou dado. Para entendermos melhor o modelo acima, vamos descrev-lo por completo.
Objeto 1 Pessoa Login ValidaLogin Pedidos Pedidos Pedidos Pedidos Pedidos Conta Conta Produtos Objeto 2 -Garom -Caixa ValidaLogin -Garom -Caixa Garom Produtos Vendas Cozinha Conta Recebimento Recibo Pedidos Tipo Generalizao Realizao Dependncia Dependncia Composio Realizao Realizao Composio Composio Realizao Composio Descrio Todos os garons e caixas so pessoas, portanto possuem atributos em comum. A tela de login chama, ou realiza, o metodo de validao do login. Para validar um login necessrio que o usurio exista. Um pedido s pode ser registrado caso o garom exista. Pedidos so formados por n produtos. A tela de vendas insere os pedidos. Ao cadastrar um pedido este automaticamente emite uma ordem para a cozinha. Uma nica conta contem n itens vendidos. Uma nica conta contem n recebimentos. Ao fechar uma conta automaticamente emitido um recibo. Um mesmo produto pode ter sido vendido em n pedidos.
Como exemplificado acima, o modelo contem as quatro agregaes bem como tambm os diferentes tipos de multiplicidade. Com base no modelo de agregao montamos os diagramas UML de seqncia e com o modelo de multiplicidade o diagrama de dados. 4.2.4 Diagrama de Seqncia O diagrama de seqncia tem como objetivo definir a ordem de chamada dos mtodos. Com este diagrama temos um controle muito simples de qual componente executa qual componente e com isto entendemos e criamos as interfaces e os retornos que cada interface deve ter. Utilizando o diagrama de seqncia podemos entender claramente a interligao e o momento de chamada. Veja abaixo os smbolos UML utilizados nos diagramas de seqncia:
Smbolo Descrio
Reproduo e distribuio livre www.marcelosincic.com.br
Verso: 2.0
Pgina 20 de 35
O b je c t 1
Objetos A linha que se estende abaixo deles onde se coloca os smbolos de ativao. Um componente se comunica com diversos outros componentes. Ativao colocado sobre a linha do objeto e se estende para definir todos os objetos e mtodos que uma determinada chamada far. Uma ativao representa um momento temporal em que um mtodo chamado e pode desencadear mais de um mtodo. Mensagem Utilizado para interligar as ativaes entre os objetos, indicando o nome do mtodo que est sendo executado. Retorno Representa o retorno que o mtodo devolve, indicando apenas um boolean (True/False) ou ento um dataset (conjunto de dados).
Message1 Message2
Abaixo temos um exemplo do diagrama de seqncia do sistema de restaurante:

L o g in V a lid a L o g in G a r o n C a ix a V a lid a r L o g in () b o o le a n D a d o s G a r o m ()
d a ta s e t
D a d o s C a ix a ()
d a ta s e t
V endas
P e d id o s
C o z in h a
C o n ta
R e c ib o
R e c e b im e n to
In c lu ir P e d id o () d a ta s e t
Im p rim ir P e d id o () b o o le a n
S o m a r P e d id o s () d a ta s e t
F e c h a r C o n ta () b o o le a n
Im p rim ir re c ib o () b o o le a n
C a lc u la r T ro c o () lo n g lo n g Calcular Troco() In c lu ir R e c e b im e n to b o o le a n
4.2.5 Diagrama de Dados O diagrama de dados gerado neste momento j identifica o nome das tabelas e das colunas. Este modelo se aproxima muito do modelo fisicamente implantado, com a diferena bsica de que o tipo de dados IDL ou tambm chamado de portvel. Para entender o diagrama siga a tabela abaixo:
Smbolo Setas de interligao Descrio Chave Estrangeira (FK) Identifica que uma tabela depende de outra. Por exemplo, o cdigo do garom na tabela de pedidos exige que este exista na tabela de garom. Chaves estrangeiras valida a tabela por coibir o cadastro em uma tabela filho caso na tabela pai no exista o correspondente.
Verso: 2.0
Pgina 21 de 35
PK Colunas em negrito
Chave Primria Serve como identificador nico em cada tabela. Por exemplo, no caso dos produtos geramos um cdigo (IDProduto) que no pode ser repetido e ficar em branco. Em uma pessoa, o RG seria uma PK Obrigatria (not null) Define que a coluna no pode estar sem preenchimento. Poderia estar com dados em branco, ou seja, o usurio pode digitar espaos em branco, mas obrigatrio colocar algo.
C a ix a G a rc o m PK ID G a rc o m Nom e Senha N -S ig n e d In te g e r C -V a ria b le L e n g th (3 0 ) N -S ig n e d In te g e r
PK
ID C a ix a Nom e Senha
N -S ig n e d In te g e r C -V a r ia b le L e n g th (3 0 ) N -S ig n e d In te g e r
P ro d u to s PK ID P ro d u to D e s c ric a o P reco E s to q u e E s t_ M in im o N -S ig n e d In te g e r C -V a r ia b le L e n g th (5 0 ) N -D e c im a l(1 0 ,2 ) N -D e c im a l(1 0 ,2 ) N -D e c im a l(1 0 ,2 ) PK FK2 FK1 ID P e d id o
P e d id o s N -S ig n e d In te g e r N -S ig n e d In te g e r N -S ig n e d In te g e r N -S ig n e d In te g e r N -S ig n e d In te g e r T -D a te & T im e
ID G a rc o m ID P ro d u to M esa Q u a n tid a d e D a ta
R e c e b im e n to PK FK2 FK1 ID R e c e b im e n to ID C a ix a ID C o n ta T ip o V a lo r N -S ig n e d In te g e r N -S ig n e d In te g e r N -S ig n e d In te g e r N -S ig n e d In te g e r N -D e c im a l(1 0 ,2 ) PK FK1 ID C o n ta
C o n ta N -S ig n e d In te g e r N -S ig n e d In te g e r N -D e c im a l(1 0 ,2 )
ID P e d id o V lT o ta l
No exemplo acima utilizamos dados portveis, uma vez que no modelo lgico apenas sugerimos os servidores e produtos que sero utilizados, mas ainda no foram definitivamente escolhidos. O tipo de dados ser automaticamente migrado no momento que for definido o produto, utilizando o tipo de dados mais prximo do definido no modelo lgico. 4.2.6 Design de Alto Nvel Chamado de High-Level Design, um prottipo de como dever ser o layout das tela de input de dados. No define em linguagem, mas define basicamente as telas permitindo que no desenvolvimento sejam seguidas estas regras. Por exemplo, podemos definir o tamanho da tela, os tipos de controles grficos utilizados, a cor e logotipos, etc. Segue abaixo o modelo de design da tela de vendas que o garom utilizar:
Verso: 2.0
Pgina 22 de 35
Login
ID do garom Senha
Vendas
Lista de categorias Lista dos produtos da categoria escolhida
Validar
Quantidade Limpar
Numero da mesa Registrar
Consultar pedidos da mesa Fechar conta da mesa Data/Hora Data/Hora e nome do garom logado
Este modelo foi elaborado levando-se em conta que nas tecnologias candidatas especificamos que o equipamento do garom seria um Pocket PC ou um Palm, por isso as telas so menores e com todos os dados contidos para evitar navegao. No h detalhes como por exemplo, os labels, data e hora real na statusbar, nome dos objetos, etc. Mas h informaes suficientes para conceituar o layout que o sistema dever adotar.
4.3 Otimizao
A otimizao como os processos de refinamento j analisados anteriormente. Nesta fase do lgico podemos verificar vrios itens:
Item verificado Descrio Redundncia Verifique se o mesmo dado no foi colocado em duas tabelas, componentes ou objetos. Muitas vezes isto pode acontecer ao estar se definindo um grande projeto. Notamos tambm isto nas interfaces grficas, muitas vezes duplicadas durante o planejamento. Especializao Cada componente deve ter uma funo distinta. Deve-se evitar componentes com funes diferentes agrupados, conceito chamado de coeso, caso eles possam ser chamados por meios diferentes ou no tem relao direta entre si. Escopo O componente tem que cumprir todas as exigncias do projeto, no contendo mais ou menos funcionalidades do que foi efetivamente contratado pelo cliente. Correlao Os relacionamentos tanto na base de dados quanto dos objetos deve estar correto. Algumas vezes podemos criar relacionamentos que no so sempre obrigatrios. Por exemplo, dizer que para cada conta temos apenas um recebimento, uma vez que alguns clientes podem dividir a conta entre si, exigindo o registro de diversos recebimentos para uma mesma conta. Tipo Neste item verificamos se as chamadas so sncronas ou assncronas. Sncronas so funes que devem acontecer em uma ordem lgica, como por exemplo, a impresso do pedido na cozinha sempre ocorre na seqncia da insero de um novo pedido pelo garom. Por outro lado a funo de fechamento de conta no acontece em decorrncia da soma dos pedidos, uma vez que o cliente pode pedir apenas uma prvia de sua conta. Funes assncronas servem para indicar operaes que podem acontecer em outro momento. Por exemplo, um DOC bancrio pode ser feito a qualquer hora do dia, mas ele s processado a meia-noite do dia em que foi registrado. Este processo muitas vezes chamado tambm de batch. Controle importante conhecer os conceitos de coeso e acoplamento. Coeso quando uma operao est to intrinsecamente outra que agrupada em um nico componente. Por exemplo, todas as vezes que eu apagar um funcionrio pai eu automaticamente apago seus filhos, e apenas apago filhos quando o pai apagado, o que gera uma alta coeso. Outro importante conceito acoplamento, que indica relacionamento entre componentes. No nosso sistema de exemplo temos acoplamento entre o componente pedido e cozinha, uma vez que todas as vezes que incluo um pedido devo imprimir o pedido. Este exemplo to acoplado que poderia em uma situao real ser coeso.
Verso: 2.0
Pgina 23 de 35
Ao terminar esta fase chegamos ao marco do final da fase de planejamento lgico e iniciamos o planejamento fsico.
5 Planejamento Modelo Fsico

5.1 Introduo
O modelo fsico formulado por pessoal altamente tcnico pois entra nos meandros do desenvolvimento do software. Apesar de ainda no ser o desenvolvimento, o modelo fsico determina como os cdigos devem ser escrito, nomes das colunas e tabelas, tamanho das colunas, nomenclatura dos componentes, regras de linguagem, componentizao em camadas, etc.
5.2 Pesquisa
Na fase de pesquisa partimos com base no modelo lgico e nos UCs para definir algumas caractersticas tcnicas, essenciais para o projeto. No modelo lgico foram definidas as tecnologias candidatas, e agora escolheremos a que mais se encaixa, utilizando alguns itens exemplificados abaixo:
Item Performance Facilidade de uso Custo beneficio Instalao Suporte Reutilizao Segurana Requisito Definir o tempo de resposta que o software deve assumir como mnimo, por exemplo, em uma aplicao web a navegao entre pginas no pode ultrapassar 5 segundos. Qual a tecnologia com mais profissionais habilitados e levando-se em conta a curva de aprendizado se teremos tempo hbil para a soluo Os gastos com treinamento e suporte compensa a implementao de uma plataforma mais barata? Qual o grau de dificuldade de instalao e entrega da tecnologia. Algumas so extremamente simples de serem usadas, mas no momento da implantao necessrio copiar dezenas de arquivos. O suporte da tecnologia em seu ambiente est habilitado ou seus profissionais no possuem conhecimento caso ocorram problemas. Qual das tecnologias candidatas permitir crescimento com reaproveitamento do que for feito. Alguns modelos de tecnologias so muito rgidos, no aceitando o acesso por outras plataformas e sistemas. Por exemplo, hoje componentes baseados em XML deve ser reconhecido em qualquer produto. A tecnologia possui realmente a segurana integrada ao software, ou a segurana apenas proprietria, ocasionando falta de conhecimento interno.
Estes so exemplos de como escolher o produto final da aplicao. Com estes parmetros pesquisados e conhecidos passamos a fase de anlise. O documento gerado neste momento segue como o exemplo abaixo:
Requisito Sistema operacional Linguagem de programao Ferramenta RAD Banco de dados Equipamento para atendimento Equipamento de caixa Segurana Tempo de resposta Apresentao Arquitetura da aplicao Servidor de Aplicao Definio Windows Server 2003 Standard Edition C# Microsoft Visual Studio .NET 2003 Microsoft SQL Server 2000 HP iPAQ 9530 com Wi-fi e Pocket PC 2003 Pentium III com RAM de 256 MB e HD de 20 GB -Active Directory para acesso a rede -Autenticao e autorizao de sistema por software O tempo de transao no deve ultrapassar 5 segundos -Windows Forms em .NET Compact Framework nos Pocket PC -Windows Forms em .NET Framework nos caixas Layered-Stateless-Client-Server COM+ no Windows 2003
Verso: 2.0
Pgina 24 de 35
5.3 Anlise
Alguns diagramas e dados so importantes e revisados neste momento. 5.3.1 Diagramas de Classe e Seqncia Revisados Primeiramente analisamos os diagramas de classe, database e seqncia para verificar e adapt-los ao produto e tecnologia escolhida. Definiremos detalhe nas classes anteriormente definidas em UML. No diagrama anterior de classes possuamos o nome dos mtodos, mas no especificamos parmetros de entrada e de sada. Neste momento iremos atualizar o modelo inserindo os parmetros que cada mtodo, ou operao, ir receber. O resultado ser o diagrama abaixo:
P ro d u to s P e d id o s + In lc u ir P r o d u t o ( in D a d o s : d a ta s e t ) : b o o l + A lt e r a r P r o d u to ( in D a d o s : d a t a s e t ) : b o o l + P r o d S e m E s to q u e ( ) : d a t a s e t + C o n s u lt a r P r o d u to s ( in I D P r o d u to : in t ) : d a ta s e t + In c lu ir P e d id o ( in D a d o s : d a ta s c a ll o o l e t) : b
Vendas + E n tr a r D a d o s ( in D a d o s : d a ta s e t ) : b o o l
C o z in h a + Im p r im ir P e d id o ( in I D P e d id o : in t) : b o o l
G aro m + D a d o s G a r o m ( in C o d ig o : s h o r t) : d a t a s e t
C a ix a C o n ta + D a d o s C a ix a ( in C o d ig o : s h o r t) : d a t a s e t + S o m a r P e d id o s ( in M e s a : s h o r t ) : d e c im a l + F e c h a r Co n tll in M e s a : s h o r t ) : b o o l ca a(
V a li d a L o g i n + V a lid a r L o g in ( in C o d ig o : s h o r t , in S e n h a : s t r in g ) : b o o l
R e c ib o + Im p r im ir R e c ib o ( in M e s a : s h o r t) : b o o l
R e c e b im e n to L o g in + E n t r a r D a d o s ( in C o d ig o : s h o r t , in S e n h a : s tr in g ) : b o o l + In c lu ir R e c e b im e n to ( in D a d o s : d a t a s e t ) : d e c im a l + C a lc u la r T r o c o ( in M e s a : s h o r t ) : d e c im a l
Note que temos os parmetros de entrada baseados nos tipos de dados do C#. Tambm foi alterado o nome das operaes. Os parmetros entre parntesis so os parmetros de entrada, aqueles enviados ao mtodo. O parmetro que aparece aps os parnteses e dois pontos o retorno do mtodo. Portanto, definimos para a funo EntrarDados no componente Login que ele receber o cdigo e a senha, onde o cdigo e um inteiro curto e a senha uma seqncia de caracteres. O retorno deste mtodo ser um booleano, indicando true ou false. Como pode ser visto na redefinio das classes, foi includo uma nova operao nos produtos, denominada ConsultarProdutos. Esse processo espiral, uma vez que podemos pedir a quem definiu o modelo lgico para validar esta alterao. A alterao aprovada pelo analista do modelo lgico permitir atualizar o diagrama de seqncia, que agora conta com mais um objeto e operao, alem de incluir os parmetros de entrada e sada, bem como os tipos de dados dos parmetros:
Verso: 2.0
Pgina 25 de 35
L o g in
V a lid a L o g in
G a r o n
C a ix a
V a lid a rL o g in := V a lid a rL o g in (C o d ig o , S e n h a ) b o o le a n D a d o s G a r o m := D a d o s G a r o m (C o d ig o )
d a ta s e t
D a d o s C a ix a := D a d o s C a ix a (C o d ig o )
d a ta s e t
Vendas
P e d id o s
P ro d u to s
C o z in h a
C o n ta
R e c ib o
R e c e b im e n to
C lu s u lta id ro d u to s ) In c lu irP e d id o := In co nirP e d rPo (D a d os := C o n s u lta rP ro d u to s (ID P ro d u to ) d a ta s e t d a ta s e t Im p rim irP e d id o := Im p rim irP e d id o (ID P e d id o ) b o o le a n
S o m a rP e d id o s := S o m a rP e d id o s (M e s a ) d e c im a l
F e c h a rC o n ta := F e c h a rC o n ta (M e s a ) b o o le a n
Im p rim irR e c ib o := Im p rim irR e c ib o (M e s a ) b o o le a n
C a lc u la rT ro c o := C a lc u la rT ro c o (M e s a ) d e c im a l d e c im a l Calcular Troco In c lu irR e c e b im e n to := In c lu irR e c e b im e n to (D a d o s ) b o o le a n
5.3.2 Diagrama de Database Revisada Revisar o database envolve apenas passar do modo portvel para o modo fsico, ou seja passar de IDL para o tipo de dados que cada banco de dados possui. O mesmo acontecer com chaves primrias, estrangeiras e ndices, sendo este ultimo criados este momento e sindicados pela sintaxe I1, I2, etc., como no esquema abaixo:
Verso: 2.0
Pgina 26 de 35
5.3.3 Diagramas de Topologia e Componentizao Aps a reviso dos modelos anteriores podemos definir os prximos trs diagramas a serem entregues. O primeiro deles o diagrama de topologia futura:
Note que com este diagrama podemos exemplificar rapidamente os equipamentos, componentes de rede e usurios que estaro interagindo com o sistema. J o modelo de componentizao servir para indicar quantos componentes fsicos (sejam estes formulrios, dll ou executveis) sero utilizados e qual o relacionamento entre eles. O modelo de componentes totalmente baseado no diagrama de classes criado na fase de modelagem lgico. Veja o exemplo abaixo com o diagrama entre os componentes:
L o g in V a lid a L o g in
S Q L S erv er
Vendas
C o z in h a
R e c e b im e n to
C o n ta
Im p r e s s o r a C o z in h a
R e c ib o
Im p r e s s o r a C a ix a
A partir do modelo de topologia e do modelo de componentizao poderemos definir o diagrama de topologia de dados e componentes. Este indica em que diferente componente fsico estar situado os componentes e dados. Como em nossa definio fomos orientados a utilizar o modelo layered-stateless-cliente-server, sabemos que os clientes iro arquivar dados localmente durante uma operao, mas que devero se comunicar constantemente com o servidor de banco de dados. Tambm entendemos pelo layered
Verso: 2.0
Pgina 27 de 35
que s componentes estaro em um servidor de componentes baseados no COM+, com processamento centralizado. Com esta definio, segue o diagrama de topologia de componentes e dados:
5.4 Racionalizao
O processo de racionalizao pode ser definido como a fase onde os modelos anteriores so repensados. No iremos na racionalizao mudar as classes e objetos, mas sim pensamos em distribuio e empacotamento. Por exemplo, at o momento temos uma classe chamada recibo que imprime um boleto sendo que esta operao sempre executada ao ser fechada uma conta. Portanto, podemos dizer que estamos lidando com alto acoplamento e portanto estas duas classes podem estar compiladas fisicamente em um nico assemblie. Para que fique claro estes conceitos e como racionalizar, precisamos entender muito bem sobre o tipo de plataforma, gerenciadores de aplicaes e linguagem que est sendo utilizada, j que as caractersticas que alistaremos agora mudam de uma para outra.
Conceito Gerenciamento de estado Opes Cliente Descrio Esta opo muito utilizada quando a aplicao ser utilizada em solues que o usurio final no pode contar com uma conexo fixa. Podemos exemplificar com os leitores de gua utilizados atualmente pelos operadores. Estes precisam ter um arquivo em memria local no coletor, uma vez que no final do dia descarregam na base de dados de cobranas. No seria possvel manter o coletor conectado. Utilizado em ambientes altamente conectados, onde todos os dados esto centralizados no servidor SQL Server, Oracle, Sysbase ou outro produto. O desenvolvimento da aplicao mais simples e alteraes refletem instantaneamente. Quando o cliente web temos o problema comum da perda de dados cada vez que o usurio abre e fecha o browser. Para persistir dados no cliente podemos usar cookies que so arquivos texto com variveis, e ler estes arquivos em pginas. O problema dos cookies existe porque alguns browsers e polticas de segurana probem este recurso por expor dados do usurio.
SQL Cookie
Verso: 2.0
Pgina 28 de 35
Application State
Design
Os dados so arquivados no servidor IIS ou COM+ de forma pblica. Muito til para guardar variveis que so comuns a todos os usurios da aplicao e que so volteis, como por exemplo, cotao do dlar. Se guardarmos a cotao em DBMS teremos o problema do alto consumo de rede, enquanto fazer a leitura uma nica vez no dia e guardar na memria do servidor de aplicao reduz este trfego de rede. Session State Este acontece quando o usurio se conecta pelo browser. Cada diferente conexo via browser uma diferente sesso. O problema neste modelo que o usurio tem um perodo de timeout baixo, o que exige rapidez nas navegaes para que a sesso no expire por inatividade. Escalabilidade Envolve criar as chamadas farms ou clusters. Esse recurso colocar cada parte da sua aplicao em um diferente servidor. Sistemas no desenvolvidos em camadas no podem ser separados, portanto no dia em que um servidor ficar lento ter que ser trocado. J em aplicaes onde os componentes so separados, podemos chegar ao ponto de colocar cada componente em um servidor de aplicao diferente. Performance Tenha bem em mente que tempo de resposta pode invalidar a aplicao. Imagine um sistema de telemarketing onde o acesso aos dados do cliente demore 40 segundos. O cliente que est pagando a ligao ir se irritar com o atendente, gerando um clima desfavorvel para sua aplicao. Gerenciamento Criar uma aplicao sem pensar na manuteno um erro comum. Se a aplicao for distribuda comercialmente ou em grande escala isto fica mais complicado. Uma aplicao monoltica instalada em 3000 maquinas, para ser atualizada ir criar um verdadeiro problema. Portanto, ao pensar em modelo de componentes, a centralizao em um servidor de aplicao torna a manuteno simples. Reutilizao Algumas partes de um componente podem ser acessadas por mais de uma diferente interface, e nestes casos a separao deste componente em pedaos menores melhoraria caso apenas uma das interfaces tenha que sofrer alteraes, e ela compartilhada entre aplicativos. Contexto Funes que envolvem contabilidade no tem qualquer relao com as operaes de vendas, portanto a separao entre elas ajuda na manuteno. Granularidade Este conceito muito importante. Alta granularidade envolve cada mtodo ou poucos mtodos por componente, enquanto baixa granularidade envolve cada componente conter todos os mtodos relativos a funo executada. Por exemplo, em nosso componente produtos temos quatro mtodos, portanto estamos com baixa granularizao, mas caso coloquemos cada um dos quatro mtodos em um diferente componente estaramos em alta granularidade.
Por fim, considere o que j foi citado anteriormente chamado de alta coeso e acoplamento. A alta coeso quando o processo chamado de atmico. Um processo atmico aquele que acontece em um nico momento, seja este temporal, funcional ou relacional. Por exemplo, podemos dizer que a impresso do recibo atmica ao fechamento da conta, pois no podemos emitir o recibo sem fechar a conta primeiro. Em contrapartida no podemos dizer que o processo de vendas seja atmico com fechar conta, uma vez que vendas no apenas faz isto, mas tambm insere pedido, portanto de baixa coeso. Quanto a acoplamento a dependncia entre componentes. Quando um componente est separado de outro mas ele obrigatoriamente precisa deste, chamamos de alto acoplamento. J componentes que so independentes so de baixo acoplamento. Muitas vezes se misturam os termos coeso e acoplamento. Para ficar claro, coeso o fato de diferentes mtodos interagirem entre si, independente se esto em um mesmo componente ou no. J o conceito de acoplamento envolve o componente estar ou no no mesmo assemblie. Levando em conta os conceitos agora levantados, vamos colocar no diagrama de distribuio o modelo de nossa aplicao:
Verso: 2.0
Pgina 29 de 35
Terminados estes modelos, temos a aplicao documentada em UML.
5.5 Modelo de Implementao e Programao

Nesta ultima fase definimos como dever ser feita a codificao do sistema. Muito dirigida aos programadores, exige alto nvel tcnico e bom experincia com desenvolvimento. A funo do modelo de programao com que todos os programadores entendam os comandos e implementaes, como por exemplo, nome de objetos, tipo de comentrios, escopo de funes, tipo de dados, etc. Segue abaixo alguns dos muitos tpicos que podem ser explorados neste modelo:
Item Tecnologia Estado Descrio Qual o tipo de recurso da tecnologia escolhida ser utilizado, como por exemplo, APIs do sistema operacional, controle transacional do COM+, nmero de pacotes que sero gerados, se utilizaremos multi-thread, formulrios MDI ou SDI, drivers para acesso a dados, etc. As classes sero implementadas em statefull (cheio) ou stateless (vazio). Stateless quando o componente recebe na lista de parmetros do mtodo todos os dados que necessita. Statefull so aplicaes onde necessrio primeiramente informar os parmetros um por um e apenas depois de todos os parmetros informados executa-se a operao que no recebe parmetros. Em nosso exemplo utilizamos sempre statefull, pois mais simples de ser utilizado e no necessita que o componente guarde dados em memria, uma vez que ele recebe o que precisa e devolve tudo o que sabe, esquecendo os valores que lhe foram informados. Assemblies podem ser in-process ou out-process. Todas as dlls so in-process, ou seja, precisam que algum programa as chame para que rodem, elas por si s no podem ser executadas de forma autnoma. Por outro lado, executveis so out-process, eles no precisam que algum os chame, eles por si s tm esta capacidade de execuo autnoma. Normalmente utilizamos um nico executvel (chamado de host) que istncia, ou chama, os componentes compilados como dlls. comum nas empresas existirem tratamentos de erro padro, exigindo que as mensagens e cdigo de erro sejam padronizados entre os sistemas. Tambm se define como e onde os tratamentos devem ser executados e disparados. Define se os dados devero estar criptografados e como isto deve ser feito, se a autenticao se far por aplicao ou pelo sistema operacional, se haver autorizao, ou seja, o acesso a cada funcionalidade ser independente, entre outros. Seja local ou em rede, em que diretrio os componentes dll e executveis devero estar copiados, assim como o nome que os diretrios recebero. Mtodos podem ser pblicos (visto por qualquer aplicao), privados (apenas vistos internamente) ou shared (visto apenas nos componentes da aplicao). Os mtodos de nosso sistema, podem ou no ser executados por outros? Se possitivo devero ser pblicos, se negativo shared ou privados. As regras de validao dos dados podem ser executadas dentro dos componentes ou diretamente nos bancos de dados por utilizar Stored Procedures, Triggers e Constraint. Apesar do modelo grfico j ter sido fornecido, precisa-se definir o tipo e tamanho da fonte, objetos que devero ser
Chamada
Tratamento de erro Segurana Distribuio Escopo de mtodos Regras de validao Design
Verso: 2.0
Pgina 30 de 35
grfico
usados (grid, boto, tab, listbox, etc), tipos de formulrios, etc.
Outros tpicos j foram abordados em otimizao do modelo lgico, onde definimos modo assncrono e sncrono e outros.
5.6 Otimizao
Como a fases de racionalizao anteriores, na otimizao feita uma reviso de todo o modelo. Esta reviso ter que ser considerada final, j que ao terminar o planejamento entrega-se aos programadores as classes com as assinaturas j codificadas na linguagem escolhida. Chamamos estes componentes de stub, uma vez que eles s contem o cabealho, lista de parmetros de entrada e sada das classes e dos mtodos. O cdigo de implementao ento escrito pelos programadores. Cada mtodo, parmetro e propriedade que os componentes e tabelas recebem so chamados de interface. Interfaces devem ser vistas como imutveis, uma vez que, por exemplo, alterar uma funo que tem trs parmetros para quatro parmetros ir causar erro nos sistemas que utilizam apenas trs parmetros. O mesmo acontece com um database, no possvel alterar colunas, para fazer isso os gerenciadores de banco criam uma tabela nova e importam os dados. Ento bom lembra-se de que interfaces devem ser bem definidas na fase de planejamento para evitar remendos posteriores. No caso do diagrama de database as ferramentas Visio, Erwin entre outras j gera os scripts de criao dos objetos, o que apenas entregue ao DBA que criar um novo banco de dados e executar o script, incluindo ndices e outras consideraes de performance que entenda ser importante.
6 Desenvolvimento
6.1 Introduo
Erroneamente se diz que esta a principal fase do projeto. Na realidade de projetos bem sucedidos esta fase a mais demorada, mas no a mais importante. Se os planejamentos foram bem feitos, haver muito pouca margem de erro. Veja por exemplo o caso das classes stubs que a fase de planejamento ir gerar em C#:
public class Conta() { public Conta() { } public decimal SomarPedidos(short Mesa) { } public bool FecharConta(short Mesa) { } }
Note que a classe est montada. Cabe ao programador agora implementar conforme as definies os cdigo que retornam dados. Levando-se em conta que no planejamento j consta como deve ser feito, temos garantia de que o sistema ir cumprir seu propsito.
Verso: 2.0
Pgina 31 de 35
Os programadores recebem tambm os diagramas de seqncia, bem como os diagramas de atividades e UCs. Com base no diagrama de atividades, como o mostrado anteriormente no planejamento conceitual, ser possvel entender claramente o que deve ser feito nos cdigos internos do mtodo. O diagrama de relacionamento, dependncia e seqncia mostram qual componente chama outro, quando e o que ele deve informar. possvel que neste momento os programadores discordem de certos passos, mas deve levar em conta que se o planejamento foi bem feito no haver muita margem para alteraes nesta altura do projeto. Por outro lado, levando-se em conta que o processo espiral, caso realmente haja inconsistncias, esta deve ser comunicada de forma apropriada e aps se levantar os dados, fazer a correo caso seja necessrio.
6.2 Provas de Conceito

Entende-se por prova de conceito reunies e verses do sistema, principalmente prottipos. Imagine nossa aplicao de exemplo e lembre-se de que ela utiliza Pocket PC, um equipamento reconhecidamente limitado quando comparado a um PC. Neste ponto as provas de conceito realizam a importante tarefa de garantir que o equipamento ir suportar a aplicao. Para a prova de conceito no necessrio estar todo o sistema pronto, nem mesmo estar desenvolvimento o sistema especificado, uma vez que se pode utilizar outros exemplos mais rpidos e simples a fim de demonstrar o entendimento correto. As provas de conceito servem principalmente para garantir que o pessoal de desenvolvimento tenha conhecimento da tecnologia e entendam a sua aplicao. Por exemplo, se formos utilizar Internet podemos desenhar um site com duas ou trs pginas de navegao para o cliente, usurio final e analistas dem aval no modelo grfico, posicionamento e tecnologia utilizada.
6.3 Verses Internas (internal releases)

Verses internas so similares as provas de conceito em objetivo, mas diferente no que demonstram. Nas provas de conceito o exemplo utilizado no necessita ser a soluo proposta, mas apenas um exerccio com a tecnologia. J as verses internas sero criadas peridica e sistematicamente. Algumas empresas como a Microsoft utilizam o conceito de daily build no final do expediente para no perodo noturno serem feitos testes com hardware, compatibilidade e bugs. Estas verses tambm podem ser criadas ao final de cada implementao, como por exemplo, ao terminar a tela de login de nosso sistema e com as tabelas de garons e caixas montadas podemos criar uma verso para que os analistas e testadores possam verificar por meio de testes prdefinidos a aplicao naquele componente especifico. Este passo pode parecer trabalhoso, mas fornece uma ferramenta extremamente til por permitir que erros sejam tratados e resolvidos antes que se tornem partes de um sistema completo. muito mais fcil corrigir erros em componentes individuais no inicio do desenvolvimento do que fazer isso com o sistema pronto, uma vez que pode ocasionar erros em cascata. Alem dos testes de uso e funcionalidade as verses internas tambm possibilitam o processo de code review. Este processo normalmente executado por um programador mais experiente que no estar testando o sistema, mas sim a forma como foi escrito. Por exemplo, se foram feitos comentrios descritivos, se os escopos esto corretos, layout conforme as especificaes, etc.
Verso: 2.0
Pgina 32 de 35
Para muitos programadores o code review um processo desnecessrio, mas quando se trabalha em grandes equipes o code review garante que qualquer programador entender o cdigo em caso de manuteno posterior. evidente esta vantagem quando imaginamos que um erro ou alterao pode ocorrer em um sistema anos aps a sua implantao. Por isso, o code review ajudar que no futuro ao ser aberto o cdigo fonte no haver surpresas.
7 Estabilizao / Testes
7.1 Introduo
A fase de estabilizao e testes tem por objetivo utilizar mtodos de testes elaborados para definir se a aplicao segue o modelo fornecido, no apenas tecnicamente, mas tambm do ponto de vista do usurio. Nem sempre todos os erros so corrigidos. Alguns erros so postergados ou documentados. Podemos exemplificar com um fogo domstico. Ao se ligar o forno com a tampa de vidro abaixada o calor do forno poder quebrar o vidro. Como este problema de difcil soluo por ser custosa, optou-se por colocar etiquetas de advertncia. Do mesmo modo, alguns erros no podem ser corrigidos e passam a ser catalogados, como por exemplo, a distancia em que o Pocket utilizado pelo vendedor pode estar da antena antes da conexo cair. Os testes a serem efetuados envolvem:
Teste Funcional Configurao Stress Performance Documentao e Help Paralelo Regresso Itens verificados Utilizando os diagramas de atividade simulamos o usurio operando o sistema. Este teste feito com diversas variaes onde tentamos provocar erros e inconsistncias. Utilizando-se diferentes hardwares e situaes termais, distancias ou outras variaes se o sistema continua funcionando, como por exemplo, afastar-se da antena do wi-fi. Pode ser feito com simuladores para verificar a carga de dados que o sistema agenta. Verifica se a performance no afetada por diversos fatores, como os testes relacionados acima. Utilizando-se do manual do usurio e do help averigua se estes no esto pulando etapas ou desatualizados, alem de esclarecedores o suficiente para o usurio final. Quando um sistema migrado simulamos uma operao no sistema antigo e no novo e o resultado no deve ser divergente para garantir que funcionalidades ou dados no esto sendo perdidos. Ao receber a correo de um erro anterior muitas vezes pode-se ter afetado outros componentes. O teste de regresso envolve testar funcionalidades relacionadas.
7.2 Convergncia de Bugs e Zero Bounce

Entende-se por convergncia de bug o momento em que o numero de erros ativos menor do que o numero de erros corrigidos. Esta curva abaixo demonstra este conceito:
Verso: 2.0
Pgina 33 de 35
Pode-se dizer que este momento importante porque demonstra que a equipe de desenvolvimento est trabalhando eficientemente. Este o momento, ou marco, em que geramos uma verso Alpha. Verses alpha so restritas a um grupo de usurios pr-escolhidos que iro iniciar testes em ambiente real, se possvel. Aps a convergncia de bugs esperamos ocorrer o marco chamado de zero bounce, momento onde o numero de bugs encontrados foram resolvidos, como mostra o diagrama abaixo:
Este marco serve para o lanamento da verso candidata (release candidate).
7.3 Verses Candidatas

Verso candidata no quer dizer que todos os erros foram resolvidos ou documentados, mas que as funes do sistema esto estveis e funcionando. A verso candidata importante porque nunca um teste em ambiente controlado simula o ambiente real do usurio final. necessrio ao criar verses candidatas estar atento e receber rapidamente, com prazo prdefinido, as opinies e erros relato pelos usurios testando. Caso no seja um mtodo gil de relatrio, o usurio ir simplesmente parar os testes ou ento ignorar o erro e esperar que outra pessoa o faa.
8 Entrega
Verso: 2.0
Pgina 34 de 35
8.1 Introduo
Chegamos a verso final do produto e agora iremos para o deployment, ou entrega, deste. Muitos sistemas timos esbarram em dificuldades ao serem instalados. Por exemplo, todos queremos ter ar condicionado, mas muitos prdios de apartamento no so fabricados com suportes, o que exige alem da compra do ar condicionado a contratao de um pedreiro, materiais e uma boa sujeira. Para minimizar estes problemas podemos criar mtodos que minimizem ou ento garantam uma boa entrega e implantao de nossa soluo.
8.2 Implantao de Tecnologias

O primeiro passo implantar as tecnologias bsicas, o que inclui sistema operacional, criao de diretrios e cpia de arquivos do sistema, bem como banco de dados e sistemas. Esse passo mais complicado quando estamos migrando sistemas existentes e neste caso sempre prudente executar backup antes da alterao, principalmente alteraes no banco de dados. Para garantir crie um plano piloto, talvez em uma filial menor ou parte dos usurio seguindo algumas regras abaixo:
Grupo Preparao Item Objetivo Treinamento Suporte Comunicao Contingncia Retorno Prazos Implementao Avaliao Relatrio Pesquisa formal Contagem de suporte Descrio Tenha documentado, aprovado e tornado pblico porque o teste est sendo realizado e quais os problemas potenciais que podem ocorrer. Treine os usurios do piloto de forma exemplar e garanta que todos entenderam bem, uma vez que o piloto falhando, a soluo naufragou. Crie um agendamento e deixe com os usurios a lista de pessoas e plantes. Deixe de fcil acesso a comunicao com o suporte, crie planos de gerao de relatrios. Tenha um plano testado para permitir sistemas paralelos caso o piloto tenha que sofrer paradas para correes. No desejvel mas melhor do que gerar prejuzos. Admita caso no esteja apto a continuar a implantao e tenha um plano bem definido para retornar um backup, por exemplo, para o sistema antigo voltar a funcionar. Prazos curtos mas que tenham ocorrido todas as situaes funcionais o ideal. Faa teste de falhas propositais no piloto. Documente os resultados da falha. Tente at mesmo gerar falhas crticas, pois ir testar como afetar o negcio e os risco sero melhor entendidos aps isso. Fornea um site ou um contato por email para os usurios enviarem suas opinies, de preferncia annimas. Esta servir para o pessoal de cargos mais altos e os diretamente envolvidos em decises para definir o nvel de satisfao com o novo sistema. Verifique quais os problemas mais comuns que geraram suporte e como foram resolvidos. Problemas comuns so erros de documentao ou de sistema.
Muito cuidado com o chamado quiet period (perodo silencioso) onde os usurios se acostumaram com a aplicao mas ainda no utilizaram funes espordicas, como por exemplo, relatrios mensais ou fechamentos. Muitas vezes o dia a dia parece estar em ordem, mas o fechamento mensal provoca perda de dados ou dados inexatos, que podem at mesmo levar a empresa a dificuldades.
8.3 Transferncia de Comando

Tendo conseguido chegar na excelncia esperada, hora de transferir comando. No modelo Microsoft, denominado MSF, ns abrangemos da concepo (viso) a entrega do produto. Mas a operao dos sistemas aps este estar implantado definida por outros modelos
Verso: 2.0
Pgina 35 de 35
padronizados de mercado como o ITIL do qual a Microsoft gerou um modelo chamado MOF, Microsoft Operational Framework. A transferncia de comando deve ser feita com muito treinamento e demonstraes, com planos de contingncia e mitigao bem documentados. Ao transferir uma operao com sucesso garantir que seus esforos em um novo projeto no sero interpelados por um projeto anterior. Dedique tempo a transferncia, no a leve como algo de menos importncia, j que voc poder ter ganhado um verdadeiro filho por fazer uma m transferncia. Outro fator importante, que se na transferncia ocorrerem problemas, todo o seu trabalho anterior pode ser denegrido e levar o rtulo de incompetncia.

Apostila de UML

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila de UML

Enviado por

Direitos autorais:

Formatos disponíveis

Verso: 2.

Reproduo e distribuio livre

Planejamento Modelo Conceitual ______________________________ 14 3.1 3.2

Estabilizao / Testes __________________________________________ 32

Reproduo e distribuio livre

1.2 Introduo a MSF / RUP

Reproduo e distribuio livre

2.2 Tcnicas de Anlise

Reproduo e distribuio livre

2.3 Use Cases e Cenrios

UC 1.2 Cliente solicita a conta

UC 1.3 Cliente paga em dinheiro

Estado Inicial Inicio da atividade

C aixa d baixo na conta e anota nos pedidos

Estado Final Final da atividade

Estado Identifica cada interao

C aixa guarda o dinheiro

Deciso Variaes que podem ocorrer

[S im ] [N o] C aixa entrega troco ao garom

G arom entrega o troco ao cliente

Reproduo e distribuio livre

S o m a r P e d id o s uses e x te n d s uses E m itir N o ta C a ix a e x te n d s uses uses

Use Case Diferentes funcionalidades

Use Identifica quem utiliza ou interage com a funcionalidade

Reproduo e distribuio livre

2.4 Refinamento e Fechamento

Cenrio UC 1.1 Cliente solicita produto

UC 1.2 Cliente solicita a conta

Reproduo e distribuio livre

3 Planejamento Modelo Conceitual

Consultar a conta da mesa Imprimir o cupom fiscal Processar a baixa do pedido

4 Planejamento Modelo Lgico

Um exemplo de tecnologias candidatas poderia ser:

Ferramenta RAD Sistema Operacional Equipamentos

C aixa + C od igo : sh ort(id l) + N om e : ch ar(idl) + S en h a : strin g(idl)

V alid aL o g in + C od igo : sh ort(id l) + S en h a : strin g(idl) + V alid ar L og in () L o g in + E ntrar D a do s()

R e c ib o + Im p rim ir re cib o()

Exemplo Um vendedor pode atender diversos clientes

Para exemplificar a multiplicidade e relacionamentos, veja o modelo abaixo:

Abaixo temos um exemplo do diagrama de seqncia do sistema de restaurante:

P ro d u to s PK ID P ro d u to D e s c ric a o P reco E s to q u e E s t_ M in im o N -S ig n e d In te g e r C -V a r ia b le L e n g th (5 0 ) N -D e c im a l(1 0 ,2 ) N -D e c im a l(1 0 ,2 ) N -D e c im a l(1 0 ,2 ) PK FK2 FK1 ID P e d id o

R e c e b im e n to PK FK2 FK1 ID R e c e b im e n to ID C a ix a ID C o n ta T ip o V a lo r N -S ig n e d In te g e r N -S ig n e d In te g e r N -S ig n e d In te g e r N -S ig n e d In te g e r N -D e c im a l(1 0 ,2 ) PK FK1 ID C o n ta

Reproduo e distribuio livre

Numero da mesa Registrar

Reproduo e distribuio livre

5 Planejamento Modelo Fsico

Reproduo e distribuio livre

Reproduo e distribuio livre

Im p rim irR e c ib o := Im p rim irR e c ib o (M e s a ) b o o le a n

C a lc u la rT ro c o := C a lc u la rT ro c o (M e s a ) d e c im a l d e c im a l Calcular Troco In c lu irR e c e b im e n to := In c lu irR e c e b im e n to (D a d o s ) b o o le a n

Reproduo e distribuio livre

Reproduo e distribuio livre

Reproduo e distribuio livre

Terminados estes modelos, temos a aplicao documentada em UML.

5.5 Modelo de Implementao e Programao

Tratamento de erro Segurana Distribuio Escopo de mtodos Regras de validao Design

usados (grid, boto, tab, listbox, etc), tipos de formulrios, etc.

6.2 Provas de Conceito

6.3 Verses Internas (internal releases)

7.2 Convergncia de Bugs e Zero Bounce

Reproduo e distribuio livre

Este marco serve para o lanamento da verso candidata (release candidate).

7.3 Verses Candidatas

Reproduo e distribuio livre