ANHANGUERA EDUCACIONAL S/A FACULDADE DE BELO HORIZONTE

Henrique Burle Melgao

APLICAO DE PADRES DE PROJETO E PRTICAS DE DESENVOLVIMENTO SOFTWARE COMO BASE UM SISTEMA DE GERENCIAMENTO DE CONSULTAS PARA CONSULTRIO ODONTOLGICO

Belo Horizonte 2010

Henrique Burle Melgao

APLICAO DE PADRES DE PROJETO E PRTICAS DE DESENVOLVIMENTO SOFTWARE COMO BASE UM SISTEMA DE GERENCIAMENTO DE CONSULTAS PARA CONSULTRIO ODONTOLGICO

Trabalho de concluso de curso apresentado ao curso de Tecnologia em Anlise e Desenvolvimento de Sistemas, da Faculdade Anhanguera, como requisito parcial a obteno do ttulo de Tecnlogo em Anlise e Desenvolvimento de Sistemas. Orientador(a): Hlio de Sousa Lima Filho.

Belo Horizonte 2010

FACULDADE ANHANGUERA DE BELO HORIZONTE Trabalho de concluso de curso intitulado Aplicao de Padres de Projeto e Prticas de Desenvolvimento Software como Base um Sistema de Gerenciamento de Consultas para Consultrio Odontolgico, apresentado ao Curso de Sistemas de Informao da Faculdade Anhanguera de Belo Horizonte, de autoria de Henrique Burle Melgao aprovado em sete de Dezembro de dois mil e dez, pela banca examinadora constituda pelos professores:

______________________________________________________ Prof. Thiago Moraes

_______________________________________________________ Prof. Sandro Renato Dias

________________________________________________________ Prof. Hlio de Sousa Lima Filho

Belo Horizonte 2010

AGRADECIMENTOS Agradeo a minha me Aurora, meu pai Osmar, meus irmos Fernanda e Osmar Jnior e a minha av Maria pelo apoio, carinho, dedicao, ateno, pacincia, confiana e pelo amor que depositaram em mim, no s nessa longa jornada, como em toda vida Essa conquista tambm dedicada aos meus grandes amigos Leandro, Frederico e David que merecem todos os agradecimentos possveis, pois sempre estivaro presentes nessa longa jornada, dispostos a me ouvir, ajudar e me compreender nos momentos difceis. Agradeo aos meus amigos Andr, Raphael e Rodrigo que muito me ensinaram e me deram fora para continuar a luta. Agradeo a meu orientador Hlio de Sousa Lima Filho pela pacincia e compreenso. Agradeo a todos os professores que estiveram comigo nessa jornada, e que merecem todo meu apreo e respeito Agradeo a Deus pelos momentos de alegrias e de grande conquistas.

Resumo

Cada vez mais a concepo e o desenvolvimento de sistemas esto se pautando em aspectos como a abstrao, a separao entre interesses funcionais e no funcionais a modularizao e a reutilizao de componentes em diferentes contextos de software, neste caso, podemos alcanar sistemas bem desenvolvidos e de fcil manuteno com a correta aplicao de padres de projeto (design patterns). Ser demonstrada neste trabalho a utilizao de algumas destas praticas de desenvolvimento, documentao e modelagem e algumas das tecnologias de desenvolvimento de softwares disponveis no mercado, para a implementao do sistema, utilizado como exemplo um sistema para controle de consultas para consultrio odontolgico.

LISTA DE SIGLAS

UML Unified Modeling Language Linguagem de Modelagem Unificada CLR Common Language Runtime
OMT

Object Modeling Technique Object- Oriented Software Engineering

OOSE

XML Extensible Markup Language SOAP Simple Object Access Protocol

WCF

Windows Communication Foundation asynchronous java and XML

AJAX

IIS Internet Information Services POO programao Orientada a Objeto SGBD Sistema Gerenciador de Banco de Dados DAO Data Access Object MVC Model View Controller

LISTA DE FIGURAS Figura 1: Classificao dos padres proposto pelo GoF .................................. 14 Figura 2: Diagrama UML para padro Strategy................................................ 15 Figura 3: O padro Singleton ........................................................................... 17 Figura 4: Estrutura do Padro DAO ................................................................. 18 Figura 5: Diagrama de Componentes .............................................................. 23 Figura 6: Diagrama de Caso de Uso ................................................................ 26 Figura 7: ITE01 Cadastrar Usurio................................................................ 28 Figura 8: ITE02 Cadastrar Paciente .............................................................. 30 Figura 9: ITE03 Cadastrar Dentistas ............................................................. 32 Figura 10: ITE04 Cadastrar Consulta............................................................ 35 Figura 11: ITE05 Agenda .............................................................................. 36 Figura 12: Diagrama de Estado........................................................................ 37 Figura 13: Modelo Entidade Relacionamento................................................... 38

SUMRIO 1 INTRODUO .......................................................................................................... 1 2 REFERENCIAL TERICO....................................................................................... 2 2.1 UML................... .................................................................................................... 2 2.1.1 Modelagem de Software .................................................................................... 3 2.1.2 Diagramas da UML ............................................................................................ 4 2.2 Plataforma .NET............................................................................................. 5 2.2.1 Visual Studio 2008.............................................................................................. 6 2.1.2 Microsoft Visual C# ............................................................................................ 7 2.1.3 NET Framework .................................................................................................. 7 2.1.4 ASP.NET 3.5 ....................................................................................................... 8 2.3 Programao Orientada a Objeto................................................................... 9 2.3.1 Classes ................................................................................................................ 9 2.3.2 Objetos .............................................................................................................. 10 2.3.3 Encapsulamento ............................................................................................... 10 2.3.4 Herana ............................................................................................................. 10 2.3.4 Polimorfismo ..................................................................................................... 11 2.4 Banco de Dados .................................................................................................. 11 2.4.1 Modelo Relacional ............................................................................................ 12 2.5 Padres de Projeto Design Patterns .............................................................. 12 2.5.1 Strategy ............................................................................................................. 15 2.5.2 Flyweight ........................................................................................................... 16 2.5.3 Singleton............................................................................................................ 16 2.5.4 DAO Data Access Objects ........................................................................... 17 2.5.5 Interfaces ........................................................................................................... 18 2.5.6 Model-view-controller (MVC) ........................................................................... 19 2.5.7 Refactoring ........................................................................................................ 20 3 DOCUMENTAO DO SISTEMA ........................................................................ 20 3.1 Arquitetura de Software ...................................................................................... 20 3.1.1 Objetivo.............................................................................................................. 20 3.1.2 Decises arquiteturais...................................................................................... 21 3.1.3 Arquitetura lgica .............................................................................................. 23 3.1.4 Diagrama de Componentes ............................................................................. 23

3.1.5 Requisitos no- funcionais .............................................................................. 24 3.1.6 Diagramas da UML .......................................................................................... 24 3.2 Caso de Uso......................................................................................................... 24 3.2.1 Lista dos Casos de Uso ................................................................................... 24 3.2.1.1 Mensagens Globais ...................................................................................... 25 3.2.1.2 Caso de Uso UC_01 Manter Usurio .......................................................... 26 3.2.1.3 ITE01 Cadastrar Usurio ........................................................................... 28 3.2.1.4 Caso de Uso UC_02 Manter Pacientes ...................................................... 28 3.2.1.4.1 ITE02 Cadastrar Paciente ...................................................................... 30 3.2.1.5 Caso de Uso UC_03 Manter Dentistas ....................................................... 31 3.2.1.5.1 ITE03 Cadastrar Dentistas ..................................................................... 32 3.2.1.6 Caso de Uso UC_04 Manter Consultas ...................................................... 33 3.2.1.6.1 ITE04 Cadastrar Consulta...................................................................... 35 3.2.1.7 Caso de Uso UC_04 Consultar Agenda ..................................................... 35 3.2.1.7.1 ITE05 Agenda ......................................................................................... 36 3.2.2 Diagrama de Estado......................................................................................... 37 3.2.3 Modelo Entidade Relacionamento MER ..................................................... 38 3.3 Vantagens percebidas na utilizao de padres de projeto............................ 38 4 CONCLUSO .......................................................................................................... 39 5 REFERNCIAS BIBLIOGRFICAS...................................................................... 40

1 INTRODUO

Atualmente, o desenvolvimento de software tem crescido no tamanho e na complexidade, fazendo com que seu projeto e construo se tornem uma tarefa bastante difcil. Isso tem motivado os engenheiros de software a obterem um melhor entendimento das caractersticas de um software. Muitos pesquisadores buscam novos paradigmas para aumentar a habilidade de modelar, projetar e construir complexos sistemas de software. Este trabalho tem como objetivo apresentar o desenvolvimento de um software passando por todas as fases, da idia at o produto final. Ser utilizando algumas tcnicas para a documentao e levantamento de requisitos, mostrando alguns dos padres de projetos (Design Patterns) que podem melhorar a forma de desenvolvimento da aplicao, tornando-a mais fcil de manter e permitir a sua extenso no futuro. O Software tem como objetivo o controle de Consultas de um consultrio Odontolgico. Resolver problemas cotidianos, auxiliando no gerenciamento da Empresa. Um consultrio odontolgico gasta um enorme tempo com marcao de consultas, ha uma ineficincia de pesquisa a Consultas, Histrico de pacientes e Dentistas e que tudo feito manualmente (consulta a cadernos e ou agendas entre outros). Tendo em vista estes problemas o software Visa estabelecer padres de marcaes de consultas, cadastro, pesquisa de Pacientes e Dentistas, possibilitando assim, uma grande reduo de gasto de tempo e dinheiro. Trabalho tambm pretende mostrar que importante informatizar as clnicas odontolgicas, de pequeno ou mdio porte, para que se possa ter mais agilidade no seu controle, atender o maior nmero de pessoas dentro do menor tempo possvel, proporcionando-lhe um atendimento gil e eficaz.

2 Sua interface grfica permite um controle de rotinas de fcil compreenso. Auxiliando no gerenciamento dos pacientes marcados aos seus respectivos dentistas, mantendo o histrico de todos os pacientes da clnica arquivados, com informaes bsicas para auxilio no seu. O projeto prope aperfeioamento na usabilidade de interface, onde haver acompanhamento com o desenvolvimento do Sistema, de acordo com o modelo Espiral (Mais Realstico).

Este software foi desenvolvido usando a linguagem C# e a ferramenta Visual Studio. NET 2008 e alguns dos padres de projetos (Design Patterns). O sistema foi documentado pela linguagem UML (Unified Modeling Language Linguagem de Modelagem Unificada) pelo fato dela ser orientado a objeto e se encaixar perfeitamente a plataforma DOT .NET

2 REFERENCIAL TERICO

2.1 UML

A UML (Unified Modeling Language Linguagem de Modelagem Unificada) Tornou-se a linguagem-padro de modelagem adotada pela de software. Apesar de a UML oferecer um grande nmero de diagramas que enfoquem tanto caractersticas estruturais quanto comportamentais de um software, no obrigatrio a utilizao de todos os diagramas propostos pela linguagem na modelagem de seus sistemas, pois cada um deles possui uma funo especifica e, algumas vezes, alguns no so necessrios em determinadas situaes ou domnios.
A UML surgiu da unio de trs metodologias de modelagem: o mtodo de Booch, o mtodo OMT (Object Modeling Technique) de Jacobson e o mtodo OOSE (Object- Oriented Software Engineering) de Rumbaugh. Estas eram, at meados da dcada de 90, as trs metodologias de modelagem orientada a objetos mais

3
populares entre os profissionais da rea de desenvolvimento de software. A unio dessas metodologias contou com o amplo apoio da Rational Software, que incentivou e financiou a unio das trs metodologias. (Guedes, 2008 P.18)

2.1.1 Modelagem de Software

De acordo com Guedes (2008) muitos profissionais afirmam que conseguem determinar todas as necessidades de um sistema de informao de cabea e que sempre trabalharam assim. Mas utilizando as mtricas de modelagem de software Como levantamento e anlise de requisitos, prototipao, tamanho do projeto, complexidade, prazos, custos, documentao, manuteno e reusabilidade, entre outros, teremos uma estimativa de custos, para determinar em quanto tempo o software estar concludo, avaliar a quantidade de profissionais necessrios para o seu desenvolvimento etc. Grandes projetos no podem ser modelados de cabea, nem mesmo as maiorias dos pequenos projetos possam s-lo, exceto talvez os extremamente simples. Porem absolutamente verdadeiro que, quanto maior e mais complexo for o sistema, maior ser a importncia da modelagem. Com a modelagem do software, alcanamos quatro objetivos. 1. Os modelos ajudam a visualizar o sistema como ele ou como desejamos que fosse. 2. Os modelos permitem especificar a estrutura ou o comportamento de um sistema. 3. Os modelos proporcionam um guia para a construo do sistema. 4. Os modelos documentam as decises tomadas. De acordo com Jacobson (2000) existem vrias maneiras de se definir um modelo. As duas maneiram mais comuns so provenientes da perspectiva de um algoritmo ou da perspectiva orientada a objeto.
A UML (Unified Modeling Language) uma linguagem-padro para a elaborao da estrutura de projetos e softwares podendo ser empregada para a visualizao, a especificao, a construo e a

4
documentao de artefatos que faam uso de sistemas complexos. E adequada para a modelagem se sistemas, cuja abrangncia poder incluir sistemas de informao corporativos a serem distribudos a aplicaes baseadas em Web e at sistemas complexos embutidos de tempo real. Seus modelos podem ser diretamente conectados a vrias linguagens de programao, isso significa que possvel mapear os modelos da UML em linguagens de programao tais como Java, C++, Visual Basic ou at tabelas de banco de dados relacionais ou o armazenamento de dados persistentes de um banco de dados orientado a objeto. (JACOBSON, 2000, p.13)

2.1.2 Diagramas da UML

Cada diagrama analisa o sistema, sob uma determinada ptica. como se o sistema fosse modelado em camadas, apresentando uma viso externa do sistema. A utilizao de diversos diagramas permite que falhas sejam descobertas, diminuindo a possibilidade da ocorrncia de erros futuros. Os diagramas da UML so representaes grficas de um conjunto de elementos, geralmente representadas como grfico de vrtices (itens) e arcos (relacionamentos). So desenhados para permitir a visualizao de um sistema sob diferentes perspectivas, ou seja, um diagrama constitui uma projeo de um determinado sistema. Na UML existem nove desses diagramas: 1. Diagrama de caso de uso. 2. Diagrama de classe. 3. Diagrama de objetos. 4. Diagrama de seqncia. 5. Diagrama de colaborao. 6. Diagrama de grfico de estado. 7. Diagrama de atividades. 8. Diagrama de componentes. 9. Diagrama de implantao. O diagrama de caso de uso exibe um conjunto de caso de uso e atores e seus relacionamentos. Diagramas de caso de uso abrangem a viso esttica de caso de uso do sistema. Esses diagramas so importantes principalmente

5 para a organizao e a modelagem de comportamentos do sistema. O diagrama de classe exibe conjunto de classes, interfaces e colaboraes, bem como seus relacionamentos. Esses diagramas so encontrados com maior freqncia em sistemas de modelagem orientados a objetos e abrangem uma viso esttica da estrutura do sistema. O diagrama de objetos exibe um conjunto de objetos e seus relacionamentos. Representa retratos estticos de instancias de itens encontrados em diagramas de classe. Tantos os diagramas de seqncias como os de colaboraes so tipos de diagramas de interaes. Um diagrama de interao exibe uma interao, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. Diagramas de interaes abrangem a viso dinmica de um sistema. O diagrama de grfico de estado exibe uma maquina de estado, formada por estados, transies, eventos e atividades. Os diagramas de grfico de estado abrangem a viso dinmica do sistema. Um diagrama de componentes exibe as organizaes e as dependncias existentes em um conjunto de componentes diagramas de componentes. Abrange a viso esttica da implementao de um sistema. O diagrama de implantao mostra a configurao dos nos de processamento em tempo de execuo e os componentes neles existentes. Abrange a viso esttica do funcionamento de uma arquitetura de implantao. 2.2 Plataforma .NET De acordo com John Sharp a programao em .NET representa um amadurecimento no processo de desenvolvimento de softwares, na qual a comercializao do mesmo passou a ser encarada como a venda de um servio e no mais como a de um simples produto, e a etapa de codificao tornou-se muito mais focada na resoluo do problema. Este ganho substancial de tempo deve-se ao fato de que o Framework .NET j possui a maioria das rotinas que os programadores eram obrigados a codificar com freqncia, e evitando o clssico retrabalho, alm do que, agora, ferramentas de desenvolvimento como o Visual Studio .NET preocupam-se em gerar de forma automtica todo o cdigo burocrtico (aquele que no tem a ver com o desenvolvimento da aplicao em si).

A plataforma .NET est dividida em quatro partes principais: Framework .NET Ncleo da plataforma .NET. Produtos .NET Produtos Microsoft que trabalham com a tecnologia .NET e se integram por meio de XML e protocolo SOAP. Linguagens .NET Linguagens desenvolvidas segundo a especificao CLR1. Servios .NET Aplicaes e servios desenvolvidos por terceiros.

2.2.1 Visual Studio 2008

As ferramentas de desenvolvimento da Microsoft oferecem suporte ao trabalho de desenvolvedores individuais, bem como de equipes de desenvolvimento.e tambm da suporte a vrias linguagens de programao inclusive quelas que usam o .NET Framework como biblioteca j suporta mais de 30 linguagens que vo desde as linguagens oferecidas pela propria Microsoft (VB .NET, C#, VC++, Jscript .NET, J# e F#) at opes para aqueles que permanecem fieis s suas origens, como COBOL .NET e Visual Perl .NET.
O C#, junto com o Visual Studio. NET 2008 compe uma ferramenta de desenvolvimento de aplicaes para a plataforma. NET. Com uma interface amigvel e integrada com os ambientes e de fcil entendimento, proporciona aos desenvolvedores a criao de aplicaes sofisticadas com todos os recursos existentes, sem ter que ficar criando parte de cdigo em um aplicativo e o restante no outro. (CAVALLARI, 2007, p.09)

CLR (Common Language Runtime) componente encarregado de gerenciar aplicaes

desenvolvidas em .NET.

2.1.2 Microsoft Visual C#

O Microsoft Visual C# uma linguagem poderosa, mas simples, voltada principalmente para os desenvolvedores que criam aplicativos usando .Net Framework. Ela herda grande parte dos melhores recursos do C++ e do Visual Basic, e pouco das inconsistncias resultando em uma linguagem mais rpida e lgica. E basicamente similar a C++ e Java, em tal extenso que muitas palavras-chaves so as mesmas. A primeira impresso de um trecho de cdigo C# que ele se parece muito com muito visualmente com C++ e Java. Por trs dessa similaridade inicial, entretanto, C# mais fcil de se aprender do que C++ e de dificuldade comparvel a Java. uma linguagem baseada na metodologia orientada a objetos. Embora tenha sido projetada para criar cdigo cujo alvo o ambiente .NET, ela em si, no faz parte do .NET. existem alguns recursos que so suportados pelo .NET, mais no pelo C#, e vice versa. O surgimento do C# 2.0 adicionou diversos recursos novos e importantes linguagem. O ambiente fornecido pelo Microsoft visual Studio 2008 torna esses poderosos recursos fceis de usar, e os podendo ate melhorar sua produtividade como desenvolvedor.

Se descrevssemos a linguagem C# e seu ambiente associando, o .NET Framework, como a mais importante tecnologia para desenvolvimento a ser utilizada por muitos anos, no estaramos exagerando. Embora C# seja uma nova linguagem de programao que foi projetada especificamente para funcionar com .NET. Usando C#, voc pode, por exemplo, escrever uma pagina Web dinmica, um componente de uma aplicao distribuda, um componente de acesso a banco de dados ou uma clssica aplicao do Windows. (ROBINSON et al, 2004, pg.23)

2.1.3 NET Framework

FRAMEWORK - o modelo da plataforma.NET para construir, instalar e rodar qualquer aplicao, no desktop ou na Internet. Para executar um programa .NET, preciso ter o Framework instalado. O .NET Framework pode ser utilizado para criar e executar diversos

8
aplicativos, desde os aplicativos de console tradicionais at as solues baseadas na Web. (SHARP, 2008, pg.45)

Conforme SHARP (2008) O .NET Framework e formado basicamente de uma gigantesca biblioteca de cdigo que usamos a partir de nossas linguagens cliente (como o C#) usando tcnicas de orientao a objeto. Essa biblioteca est categorizada em diferentes mdulos, de forma que ns usamos partes deles dependendo dos resultados que desejamos alcanar. Por exemplo, um mdulo contem os blocos de construo para aplicativos Windows, outro para networking e um terceiro, para desenvolvimento na Web. Alguns mdulos esto divididos em submdulos mais especficos, como um mdulo para a construo de Web services dentro do mdulo para desenvolvimento na Web. Em contraste com o cdigo nativo tradicional, o cdigo gerenciado escrito em linguagens suportadas pelo .NET Framework (C#, J#, C++, visual basic, entre outros.) e compilado no Intermediate Language e depois traduzido em cdigo de mquina antes de ser executado.

2.1.4 ASP.NET 3.5

O ASP.NET e o Visual Studio oferecem excelentes ferramentas para escrever aplicativos web. Ele est disponvel h quase uma dcada, representando um grande avano em relao aos mtodos anteriores de desenvolvimento web, e fornece um ambiente de desenvolvimento orientado bem definido.
Os principais recursos introduzidos pelo ASP .NET 3.5 incluem suporte programao estilo asynchronous java and XML (AJAX) e suporte ao Windows Communication Foundation (WCF). Alm disso, o suporte ao ASP .NET no Vsual Studio aumentou muito: o designer melhorou bastante e o Visual Studio inclui novos modelos para gerar aplicativos AJAX e WCF. (SHEPHERD, 2009, p.11).

O ASP.NET vem evoluindo gradualmente desde sua primeira verso a 1.0 introduziu a plataforma um modelo de extensibilidade vivel, um modelo de processamento de controle de servidor e vrios outros recursos para tornar o

9 desenvolvimento de sites muito fcil. O ASP.NET 2.0 levou o ASP.NET 1.X a um nvel mais alto e abriu caminho na estrutura para os recursos implementados com mais freqncia. O ASP.NET 3.5 traz dois recursos novos importantes, o AJAX e o suporte hospedagem de aplicativos WCF atravs do IIS/ASP.NET2 2.3 Programao Orientada a Objeto Programao Orientada a Objeto ou, abreviadamente, POO, um paradigma de programao de computadores onde se usam classes e objetos. Ela implementada pelo envio de mensagens a objetos. Cada objeto responder s mensagens conhecidas por este, e cada objeto poder enviar mensagens a outros, para que sejam atendidas, de maneira que ao final do programa, todas as mensagens enviadas foram respondidas, atingindo-se o objetivo do programa. Programao Orientada a Objetos, tcnicas e artefatos ditos orientados a objetos incluem linguagens, sistemas, interfaces, ambientes de desenvolvimento, bases de dados entre outros. (Santos, 2003).

2.3.1 Classes

Conforme Santos (2003), classes so estruturas das linguagens de programao orientadas a objetos para conter, determinado modelo, os dados que devem ser representado e as operaes que devem ser efetuadas com estes dados. Cada classe deve conter um nome que seja facilmente associvel ao modelo que a classe representa. Uma classe representa um conjunto de objetos que possuem caractersticas e comportamentos comuns e de agora em diante, diremos que um objeto uma instncia de uma determinada classe, ou seja, criaremos os objetos baseados nas caractersticas definidas nas classes.

IIS (Internet Information Services) - Permite publicar contedo e disponibilizar arquivos e

aplicaes em um ambiente Internet/Intranet.

10 2.3.2 Objetos

Um objeto ou instncia uma materializao da classe, e assim pode ser usado para representar dados e executar operaes. Para que os objetos possam ser manipulados, necessria a criao de referncia a este objeto, que so basicamente variveis do tipo da classe. De um modo geral podemos encarar os objetos como sendo os objetos fsicos do mundo real, tal como: carro, avio, cachorro, casa, telefone, computador, entre outros, por isso que s vezes dito que orientao a objetos representa os problemas mais prximos ao mundo real, dando assim mais facilidade programao como um todo. (SANTOS, 2003).

2.3.3 Encapsulamento

O conceito de encapsulamento vem do fato de se combinar os dados (atributos) e o cdigo que manipula estes dados (mtodos) em um nico Objeto. Ele garante que a nica forma de acesso aos dados atravs dos mtodos disponveis ao usurio (chamados pblicos). Os demais mtodos e os atributos da classe ficam sendo privados, ou seja, apenas funes-membro da classe tm acesso direto aos mesmos. Em muitos casos ser desejvel que os dados no possam ser acessados ou usados diretamente, mas somente atravs das operaes cuja especialidade ser a manipulao dos dados. (SANTOS, 2003).

2.3.4 Herana

Herana a propriedade dos objetos que permite a criao de uma hierarquia entre eles, onde os descendentes herdam o acesso ao cdigo e estruturas de dados dos seus ancestrais. Coad e Yourdon (1992) definem Herana como um Mecanismo para expressar a similaridade entre classes, simplificando a definio de Classes

11 similares a outras que j foram definidas. Ela representa generalizao e especializao, tornando atributos e servios comuns em uma hierarquia de Classe.

2.3.4 Polimorfismo

De acordo com Coad e Yourdon (1992), polimorfismo a propriedade de uma ou mais classes responderem a mesma mensagem, cada uma de uma forma diferente. Este conceito til para distinguir mensagens de um mtodo. Um objeto emissor envia uma mensagem, se o objeto receptor implementa um mtodo com a mesma assinatura, ele poder respond-la. Diferentes respostas sero possveis, dependendo de como os mtodos dos receptores esto implementados. O polimorfismo implementado pelo uso de sobrecarga de funes.

2.4 Banco de Dados

O primeiro Sistema Gerenciador de Banco de Dados (SGBD) comercial surgiu no final de 1960 com base nos primitivos sistemas de arquivos disponveis na poca. Os SGBDs evoluram desses sistemas de arquivos de armazenamento em disco, criando novas estruturas de dados com o objetivo de armazenar informaes. Com o tempo, passaram a utilizar diferentes formas de representao, ou modelos de dados, para descrever a estrutura das informaes contidas em seus bancos de dados. Atualmente, os seguintes modelos de dados so normalmente utilizados so: modelo hierrquico, modelo em redes, modelo relacional (amplamente usado) e o modelo orientado a objetos. (DATE, 2000). Um Sistema Gerenciador de Banco de Dados (SGBD) constitudo por um conjunto de dados associados a um conjunto de programas para acesso a estes dados. O conjunto de dados, chamado de banco de dados, contm informaes sobre que necessitam serem guardadas. O principal objetivo de

12 um SGBD proporcionar um ambiente tanto conveniente quanto eficiente para recuperao e armazenamento das informaes do banco de dados. (SILBERSCHATZ et al, 1999)
A importncia da informao na maioria das organizaes que estabelece o valor do banco de dados tem determinado o desenvolvimento de um grande conjunto de conceitos e tcnicas para a administrao eficaz dos dados. (SILBERSCHATZ et al, 1999, p.01).

2.4.1 Modelo Relacional

Segundo Date (2000) o modelo relacional apareceu devido a necessidades aumentar a independncia de dados nos sistemas gerenciadores de banco de dados, prover um conjunto de funes apoiadas em lgebra relacional para armazenamento e recuperao de dados. O Modelo relacional revelou-se ser o mais flexvel e adequado ao solucionar os vrios problemas que se colocam no nvel da concepo e implementao da base de dados. A estrutura fundamental do modelo relacional a relao (tabela). Uma relao constituda por um ou mais atributos (campos) que traduzem o tipo de dados a armazenar. Cada instncia do esquema (linha) chamada de tupla (registro). O modelo relacional no tem caminhos pr-definidos para se fazer acesso aos dados como nos modelos que o precederam. O modelo relacional implementa estruturas de dados organizadas em relaes, porm, para trabalhar com essas tabelas, algumas restries precisaram ser impostas para evitar aspectos indesejveis, como: Repetio de informao, incapacidade de representar parte da informao e perda de informao. Essas restries so: integridade referencial, chaves e integridade de junes de relaes.

2.5 Padres de Projeto Design Patterns

Segundo Gamma (1995), Design Partters So utilizados para melhorar a forma que aplicaes so construdas e documentadas, permitindo o reuso das

13 solues. Os padres so utilizados quando h necessidade de executar diferentes algoritmos de acordo com a situao, e tambm quando precisamos diminuir o uso de memria em aplicaes construdas sob o paradigma da orientao a objeto. Podemos definir design patterns como solues bem experimentadas para problemas conhecidos. Apesar de o termo ser bastante conhecido na Engenharia de Software, ele teve origem na Engenharia Civil, atravs dos trabalhos do arquiteto austraco Chistopher Alexander que, nas dcadas de 60 e 70, produziu um mtodo estruturado para descrio de boas prticas de projeto dentro de uma rea de conhecimento.
Os padres de projeto so descries de objetos que se comunicam e classes que so customizadas para resolver um problema genrico de design em um contexto especfico (GAMMA, HELM, VLISSIDES, JOHNSON, 1995)

Segundo o GOF, os Design Patterns so divididos em trs categorias: Criacionais - Factory Method, Abstract Factory, Builder, Prototype, Singleton; Estruturais - Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy; Comportamentais - Interpreter, Template Method, Chain of Responsability, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Visitor.

14

Figura 1: Classificao dos padres proposto pelo GoF3

O desenvolvimento orientado a objetos surgiu para suprir as falhas encontradas no modelo estruturado, porm se seus conceitos forem aplicados de forma impensada, as consequncias podem ser piores. Para evitar que esses erros sejam cometidos, um estudo baseado nas idias de Christopher Alexander resultou nos padres de projeto, um conjunto de solues para problemas recorrentes. Implementadas para o modelo orientado a objetos e que constituem boa prtica para o mesmo, mostram como preparar um modelo pronto para eventuais alteraes. Um trabalho realizado pela GOF (Gang of Four)4, gangue dos quatro, classificou alguns padres, impulsionou e difundiu o uso dos mesmos, mas os padres no se resumem aos classificados pela GOF, existem vrios padres criados para resolver os mais diversos problemas. Contudo, o uso indiscriminado de padres pode levar a outros problemas, chamados de antipadres. (STRATEGY e FLYWEIGHT, 2010)

3
4

Fonte: GAMMA, 2010

Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, tambm conhecidos como

GoF, ou Gang of Four.

15

2.5.1 Strategy

O padro Strategy consiste em se possuir vrios algoritmos, ou estratgias, encapsulados em uma classe chamada Context. O programa cliente pode selecionar um desses diferentes algoritmos, de acordo com a situao. Em alguns casos, a classe Context pode at decidir qual a melhor no os momento. j Essa ou escolha estender feita em tempo de execuo. e Com esse padro, podemos mais facilmente adicionar novos algoritmos, alterar existentes suas funcionalidades. (STRATEGY FLYWEIGHT, 2010) O Context a classe que mantm a informao contextual para que um algoritmo possa funcionar. Serve de mediador entre o cliente e os algoritmos. O Strategy a interface, o contrato que define todas as operaes comuns que o algoritmo deve suportar. E o ConcreteStrategy so os prprios algoritmos. Podemos ter quantas classes desse tipo forem necessrias, cada uma representando um algoritmo diferente.

Figura 2: Diagrama UML para padro Strategy

Fonte: Artigo .net magazine 72, 2010

16

2.5.2 Flyweight

O objetivo do padro Flyweight minimizar o uso de memria no armazenamento de vrios objetos atravs do compartilhamento das informaes em comum que essas instncias possuem. Quando trabalhamos com orientao a objetos, utilizamos classes para representar cada parte das aplicaes. Com essa abordagem temos vantagens da programao orientada a objetos, como herana, polimorfismo e encapsulamento, no entanto podemos introduzir um gasto na manuteno de toda essa estrutura de objetos. nesse problema que o Flyweight atua. (STRATEGY e FLYWEIGHT, 2010) Este padro especialmente indicado para os casos de aplicaes com um grande nmero de objetos com muitas informaes que devem ser armazenados em memria. Do outro lado, ele no deve ser utilizado em situaes em que precisamos fazer comparaes entre os objetos, j que como eles sero compartilhados, esse tipo de ao se torna invivel. Flyweight um exemplo de armazenamento versus processamento. Neste padro, o ganho no armazenamento obtido na reduo de objetos na memria. No entanto, h a penalidade de desempenho, com a necessidade de um processamento maior da aplicao, visto que h a necessidade de transferir dados entre objetos e localizar objetos no repositrio.

2.5.3 Singleton

De acordo com o GOF, o objetivo do Singleton garantir que uma classe possua apenas uma instncia dentro da sua aplicao e que esta instncia possua um ponto de acesso global a todo o sistema. O Singleton precisa garantir que no teremos duas instncias de um determinado objeto em nosso sistema. (Patterns na prtica, 2010).

17

Como podemos notar na Figura 3, a implementao tradicional do Singleton prev que haja um atributo privado e esttico do tipo da classe, aqui no exemplo chamado de FInstance. Esse atributo onde ficar a nica instncia de nosso objeto.

Figura 3: O padro Singleton6

2.5.4 DAO Data Access Objects

Existe um padro para a criao da camada de persistncia. Ele se chama DAO Pattern. O DAO(Data Access Object) Pattern prope que tenhamos todas essas operaes CRUD de forma transparente. O padro DAO consiste em abstrair o mecanismo de persistncia utilizado na aplicao. A camada de negcios acessa os dados persistidos sem ter conhecimento se os dados esto em um banco de dados relacional ou um arquivo XML. O padro DAO esconde os detalhes da execuo da origem dos dados (SUN, 2007). Data Access Objects, visa separar toda a parte de acesso a dados em classes especficas para esta tarefa. Isso aumenta a coeso do cdigo, j que separamos o modelo e sua regra de negcio dos cdigos SQL para persistncia e recuperao de dados do banco. Normalmente temos uma classe DAO para cada domnio da aplicao. Isso pode parecer ruim, pois aumentaramos consideravelmente o nmero de classes do sistema. Mesmo assim a aplicao deste Pattern interessante, pois mantemos centralizado em

Fonte: Artigo .NET Magazine 76, 2010

18 uma nica classe todo o cdigo de acesso a dados referente a um determinado modelo. A figura 4 apresenta a estrutura do padro DAO. A classe DataAccessObject encapsula o acesso aos dados, que por sua vez mantido pela classe DataSource que pode ser um arquivo XML, uma base de dados ou algum servio remoto. A classe BusinessObject representa a aplicao, ou tambm conhecida como cliente do padro, que usa um objeto DataAccessObject. Ao utilizar esse objeto DataAcessObject, o objeto cliente recebe ou envia um objeto TransferObject. Esse objeto contm os dados a serem enviados ou trazidos da origem dos dados, e normalmente referem-se aos campos de um registro.

Figura 4: Estrutura do Padro DAO

2.5.5 Interfaces

Quem programa orientado a interfaces consegue criar sistemas altamente escalonveis, com baixssimo grau de acoplamento e de fcil manuteno. As interfaces ainda favorecem a separao de conceitos e responsabilidades e agilizam a programao em equipe, tornando as partes do sistema como peas de Lego que podem ser encaixadas de diversas formas.

Fonte: SUN, 2007

19 Interfaces ajudam a separar o desenvolvimento das classes ou mdulos entre vrios programadores, inclusive de empresas diferentes. Basta que as interfaces sejam combinadas ou convencionadas corretamente, como um contrato, e que tenham mtodos com escopo, objetivos, entradas e sadas bem definidas. Uma interface declarada de forma muito semelhante a uma classe, porm, ela no possui implementao alguma, ela apenas diz como as coisas devem ser feitas. Interfaces so usadas nos mais variados cenrios da programao. O prprio ASP.NET, em sua arquitetura de providers (a partir da verso 2.0), delega a maioria das funes a classes abstratas e interfaces. Servios como Login, Profiles, Membership, por exemplo, referenciam interfaces, de forma que voc possa substituir a implementao padro do framework por uma customizada. 2.5.6 Model-view-controller (MVC)

MVC (Model-View-Controller) consiste em um padro de arquitetura de software que tem por objetivo prover um design claro para separar diferentes responsabilidades em uma aplicao interativa. Com o aumento da complexidade das aplicaes desenvolvidas torna-se fundamental a separao entre os dados (Model) e o layout (View). Desta forma, alteraes feitas no layout no afetam a manipulao de dados, e estes podero ser reorganizados sem alterar o layout. O model-view-controller resolve este problema atravs da separao das tarefas de acesso aos dados e lgica de negcio. Aplicar o paradigma MVC torna possvel o desacoplamento de trs componentes de uma aplicao: acesso aos dados, lgica de negcio e interao com o usurio. (METSKER, 2004). Na camada de viso (View) tem-se a parte visual do software que o que chega ao usurio final. A viso no deve ter nenhuma lgica de cdigo, apenas exibio dos dados. Na camada de controle (Controller) onde fica

20 todo o cdigo de gerenciamento da aplicao, onde sero processadas todas as requisies feitas atravs da interface. No modelo (Model) so definidos propriedades e atributos dos seus personagens, feito tambm a persistncia dos dados em questo. 2.5.7 Refactoring

Refactoring trata-se de um processo que tem como principais objetivos tornar o cdigo mais legvel e com maior manutenibilidade. Menciona-se processo, pois refactoring no consiste em apenas mudar o cdigo que j funciona, pois quando h qualquer tipo de alterao, h riscos de introduo de novos bugs. Refactoring algo maior, que envolve pequenos passos, testes, disciplina e fora de vontade. Serve para melhorar evolutivamente o cdigo atravs de pequenas incurses, sejam em novas aplicaes ou durante a manuteno corretiva e evolutiva das existentes. Parte-se da premissa que no realizaremos o melhor design da primeira vez que um cdigo escrito. Mart Fowler Descreve refactoring sendo uma alterao realizada na estrutura interna do software para torn-lo fcil de entender e barato para se modificar, sem alterar o comportamento externo.

3 DOCUMENTAO DO SISTEMA 3.1 Arquitetura de Software

3.1.1 Objetivo

Este documento apresenta os principais aspectos arquiteturais do projeto Sistema de gerenciamento de Consultas para consultrio odontolgico. So detalhadas as decises arquiteturais, a arquitetura lgica e

21 fsica do sistema, a elaborao do projeto de software e as estratgias para atendimento dos requisitos no-funcionais.

3.1.2 Decises arquiteturais

Decises arquiteturais
Descrio do Problema: Alternativa escolhida .NET Framework Optei por esta plataforma por se uma tecnologia que est em ascenso no mercado, dar suporte para todas as necessidade do projeto e por j ter um conhecimento previu na mesma. Justificativas Justificativas Definir plataforma de desenvolvimento

Alternativas descartadas JAVA

A utilizao de tecnologias Microsoft torna o desenvolvimento mais simples e agiu

Descrio do Problema: Alternativa escolhida 3.5 Alternativas descartadas 4.0

Definir verso da plataforma de desenvolvimento Justificativas

Alm da verso 3.5 do .net framework ser a mais recente em produo, ela vem com timos recursos de workflow e integrao entre sistemas. Justificativas

A verso ainda beta e no estvel.

Descrio do Problema: Alternativa escolhida ASP.NET WebForms 2.0 Alternativas

Definir framework para desenvolvimento WEB dentro da plataforma Microsoft .NET Justificativas

J possuo conhecimento desta tecnologia, os componentes visuais e de controle permitem maior agilidade no desenvolvimento. Justificativas

22
descartadas ASP.NET MVC 2.0 A verso do ASP.NET MVC que d boa produtividade, ainda est em beta e no est estvel.

Descrio do Problema: Alternativa escolhida Crystal Reports 10.5 Alternativas descartadas Reporting Services

Definir tecnologia para gerao de relatrios Justificativas

Tecnologia padro de mercado, de fcil integrao com a plataforma Microsoft .NET e que oferece produtividade satisfatria. Justificativas

As justificativas usadas para a escolha do Crystal Reports descartam o uso desta ferramenta.

Descrio do Problema: Alternativa escolhida ASP.NET AJAX Alternativas descartadas

Definir framework para utilizao de AJAX Justificativas

A equipe j possui conhecimento desta tecnologia, framework desenvolvido pela prpria Microsoft. Justificativas

Alternativas ao ASP.NET AJAX geralmente so desenvolvidas por terceiros e na maioria dos casos deve-se comprar licena para uso.

Descrio do Problema: Alternativa escolhida SQL Server Express 2005 Alternativas descartadas

Definir SGBD da aplicao Justificativas

o sistema gratuito disponibilizado pela Microsoft que atende todas as necessidades do projeto. Justificativas

As justificativas usadas para a escolha do SQL Server Express 2005 eliminam as demais opes.

23 3.1.3 Arquitetura lgica

A arquitetura lgica apresenta a dependncia entre os componentes, pacotes e mdulos de um sistema. Uma arquitetura de referncia, mostrando a estrutura padro de desenvolvimento deve ser apresentada como guia para o desenvolvedor. 3.1.4 Diagrama de Componentes

Diagrama de Componentes Nvel 01

Integrao Externa
BD_odonto_clin

Modelo

CRN_odonto_clin

Controle

Viso

Odonto_Clin http

Ajax Control tool Kit

Figura 5: Diagrama de Componentes.

24 3.1.5 Requisitos no- funcionais

Requisitos no-funcionais
Requisito RNF_1 Estratgia/soluo adotada Toda vez que houver a necessidade de formatar um valor, usar o mtodo ToString(PARAM). Onde PARAM pode assumir, entre tantos, os valores a seguir: N2: Formata um valor para um nmero com duas casas decimais C3: Formata um valor para moeda com trs casas decimais RNF_2 RNF_3 RNF_4 Ser criado um procedimento na basepage (que automaticamente ser comum a todas as pginas) que verificar se o usurio tem permisso na pgina solicitada. O sistema ser desenvolvido e testado no Internet Explorer 7 respeitando suas restries, padres e comportamentos. Navegao por TAB: As telas sero desenvolvidas de forma que possibilite essa funcionalidade; ALT+Tecla de atalho para acessar os campos: Todos os campos de entrada de dados devem ter a propriedade AccessKey configurada para a Tecla de atalho correspondente ao campo. No texto do Label referente ao campo, deve-se sublinhar a letra referente tecla de atalho, para facilitar a navegao do usurio. Exemplo: Nome:

No exemplo acima, digamos que a propriedade AccessKey do TextBox foi configurada com o valor n. Ento o texto do label do campo (Nome:) teve a letra N sublinhada. Boto padro ser acessado com [ENTER]: s colocar o contedo dentro de um <asp:Panel /> e configurar a propriedade do controle DefaultButton contendo o ID do boto.

3.1.6 Diagramas da UML 3.2 Caso de Uso 3.2.1 Lista dos Casos de Uso

Lista dos Casos de Uso ID

UC_1 UC_2

Nome

Manter Usurio Manter Pacientes

25 Manter Dentistas Manter Consulta Manter Agenda

UC_3 UC_4 UC_5

3.2.1.1 Mensagens Globais

Descrio

MSG_1 MSG_2 MSG_3 MSG_4 MSG_5 MSG_6 MSG_7 MSG_8 MSG_9

Registro includo com sucesso. Registro(s) excludo(s) com sucesso. Registro alterado com sucesso. Usurio sem permisso de acesso Nenhum dado encontrado O campo <<nome do campo>> obrigatrio Selecione apenas 1 registro. Selecione no mnimo 1 registro. O usurio <nome_do_usurio> j se encontra cadastrado.

26

Figura 6: Diagrama de Caso de Uso.

3.2.1.2 Caso de Uso UC_01 Manter Usurio

Objetivo Criar e manter usurios utilizados internamente pelo sistema. Este caso de uso permitir a criao e a edio de usurios utilizados pelo sistema.

Atores Primrios e Secundrios Administrador da ferramenta Pr-Condies de Execuo O ator deve ter permisso de acesso ao sistema.

27 Fluxo Principal Manter Usurio

O caso de uso comea quando o ator acessa o menu Segurana -> Usurio 1. Sistema exibe a interface ITE01 Cadastrar Usurio. 2. Sistema obtm os dados e exibe no container Resultado. 3. Fim do fluxo.

Fluxos Alternativos

FA01 Cadastrar Usurio

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. Administrador preenche os dados do novo usurio. 2. Sistema mantm os dados no banco. 3. Fim do fluxo.

FA02 Alterar Usurio

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. Administrador seleciona o usurio no container. 2. Administrador altera os dados do usurio. 3. Sistema mantm os dados no banco. 4. Fim do fluxo.

FA03 Excluir Usurio

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. Administrador seleciona o usurio no container. 2. Administrador aciona o boto excluir. 3. Sistema exclui os dados no banco. 4. Fim do fluxo.

Fluxos de Exceo
EX01 Usurio sem permisso de acesso O sistema exibe a mensagem: MSG_04.

EX02 - Dados no encontrados O sistema exibe a mensagem: MSG_05

28

EX03 Usurio seleciona mais de um registro O sistema exibe a mensagem MSG_G7. EX04 Usurio no seleciona nenhum registro O sistema exibe a mensagem MSG_G8.

3.2.1.3 ITE01 Cadastrar Usurio

Figura 7: ITE01 Cadastrar Usurio.

3.2.1.4 Caso de Uso UC_02 Manter Pacientes

Objetivo Criar e manter Pacientes utilizados internamente pelo sistema. Este caso de uso permitir a criao e a edio de Pacientes utilizados pelo sistema.

Atores Primrios e Secundrios

29
Administrador da ferramenta. Usurios da ferramenta.

Pr-Condies de Execuo
O ator deve ter permisso de acesso ao sistema.

Fluxo Principal Manter Paciente

O caso de uso comea quando o ator acessa o menu Principal-> Paciente 1. Sistema exibe a interface ITE02 Cadastrar Paciente. 2. Sistema obtm os dados e exibe no container Resultado. 3. Fim do fluxo.

Fluxos Alternativos

FA01 Cadastrar Paciente

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. Usurio preenche os dados do novo Paciente. 2. Sistema mantm os dados no banco. 3. Fim do fluxo.

FA02 Alterar Paciente

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. 2. 3. 4. 5. Usurio Preenche o filtro para pesquisar um paciente. Usurio seleciona o paciente no container. Usurio altera os dados do paciente. Sistema mantm os dados no banco. Fim do fluxo

FA03 Excluir Paciente

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. Usurio Preenche o filtro para pesquisar um paciente. 2. Usurio seleciona o paciente no container. 3. Sistema exclui os dados no banco. 4. Fim do fluxo.

30 Fluxos de Exceo
EX01 Usurio sem permisso de acesso O sistema exibe a mensagem: MSG_04.

EX02 - Dados no encontrados O sistema exibe a mensagem: MSG_05

EX03 Usurio seleciona mais de um registro O sistema exibe a mensagem MSG_G7. EX04 Usurio no seleciona nenhum registro O sistema exibe a mensagem MSG_G8.

3.2.1.4.1 ITE02 Cadastrar Paciente

Figura 8: ITE02 Cadastrar Paciente.

31

3.2.1.5 Caso de Uso UC_03 Manter Dentistas

Objetivo
Criar e manter Dentistas utilizados internamente pelo sistema. Este caso de uso permitir a criao e a edio de Dentistas utilizados pelo sistema. Atores Primrios e Secundrios
Administrador da ferramenta. Usurios da ferramenta.

Pr-Condies de Execuo
O ator deve ter permisso de acesso ao sistema.

Fluxo Principal Manter Dentista

O caso de uso comea quando o ator acessa o menu Principal-> Dentistas 1. Sistema exibe a interface ITE03 Cadastrar Dentistas. 2. Sistema obtm os dados e exibe no container Resultado. 3. Fim do fluxo.

Fluxos Alternativos

FA01 Cadastrar Dentista

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. Usurio preenche os dados do novo Dentista. 2. Sistema mantm os dados no banco. 3. Fim do fluxo.

FA02 Alterar Dentista

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. Usurio Preenche o filtro para pesquisar de um Dentista. 2. Usurio seleciona o Dentista no container.

32
3. Usurio altera os dados do Dentista. 4. Sistema mantm os dados no banco. 5. Fim do fluxo.

FA03 Excluir Dentista

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. Usurio Preenche o filtro para pesquisar um Dentista. 2. Usurio seleciona o Dentista no container.

3. Sistema exclui os dados no banco. 4. Fim do fluxo. Fluxos de Exceo

EX01 Usurio sem permisso de acesso O sistema exibe a mensagem: MSG_04. EX02 - Dados no encontrados O sistema exibe a mensagem: MSG_05 EX03 Usurio seleciona mais de um registro O sistema exibe a mensagem MSG_G7. EX04 Usurio no seleciona nenhum registro O sistema exibe a mensagem MSG_G8.

3.2.1.5.1 ITE03 Cadastrar Dentistas

Figura 9: ITE03 Cadastrar Dentistas.

33

3.2.1.6 Caso de Uso UC_04 Manter Consultas

Objetivo Criar e manter Consultas utilizadas internamente pelo sistema. Este caso de uso permitir a criao e a edio de Consultas utilizadas pelo sistema. Atores Primrios e Secundrios
Administrador da ferramenta. Usurios da ferramenta.

Pr-Condies de Execuo
O ator deve ter permisso de acesso ao sistema.

Fluxo Principal Manter Consulta

O caso de uso comea quando o ator acessa o menu Principal-> Consultas 1. Sistema exibe a interface ITE04 Cadastrar Consulta. 2. Sistema obtm os dados e exibe no container Resultado. 3. Fim do fluxo.

Fluxos Alternativos

FA01 Cadastrar Consulta

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. 2. 3. 4. 5. Usurio Preenche o filtro para pesquisar um paciente. Usurio seleciona o paciente no container. Usurio preenche os dados da nova Consulta. Sistema mantm os dados no banco. Fim do fluxo.

34

FA02 Alterar Consulta

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. 2. 3. 4. 5. 6. Usurio Preenche o filtro para pesquisar um paciente. Usurio seleciona o paciente no container. Usurio Seleciona A consulta A ser alterada. Usurio altera os dados doa consulta. Sistema mantm os dados no banco. Fim do fluxo.

FA03 Excluir Consulta

O fluxo comea a partir do passo 2 do Fluxo Principal. 1. Usurio Preenche o filtro para pesquisar um paciente. 2. Usurio seleciona o paciente no container. 3. Usurio seleciona A consulta a ser Excluda. 4. Sistema exclui os dados no banco. 5. Fim do fluxo.

Fluxos de Exceo
EX01 Usurio sem permisso de acesso O sistema exibe a mensagem: MSG_04. EX02 - Dados no encontrados O sistema exibe a mensagem: MSG_05 EX03 Usurio seleciona mais de um registro O sistema exibe a mensagem MSG_G7. EX04 Usurio no seleciona nenhum registro O sistema exibe a mensagem MSG_G8.

35 3.2.1.6.1 ITE04 Cadastrar Consulta

Figura 10: ITE04 Cadastrar Consulta.

3.2.1.7 Caso de Uso UC_04 Consultar Agenda

Objetivo
Visualizar Consultas agendadas no sistema. Este caso de uso permitir a visualizao de Consultas agendadas e seus respectivos pacientes e dentistas cadastrados pelo sistema.

Atores Primrios e Secundrios

Administrador da ferramenta. Usurios da ferramenta.

Pr-Condies de Execuo
O ator deve ter permisso de acesso ao sistema.

36

Fluxo Principal Consultar Agenda

O caso de uso comea quando o ator acessa o menu Principal-> Agenda 4. Sistema exibe a interface ITE05 Agenda. 5. Usurio Seleciona uma data no calendrio. 6. Usurio seleciona um dentista cadastrado. 7. Usurio Preenche o filtro para pesquisar um paciente. 8. Sistema obtm os dados e exibe no container Resultado. 9. Fim do fluxo.

Fluxos de Exceo
EX01 Usurio sem permisso de acesso O sistema exibe a mensagem: MSG_04. EX02 - Dados no encontrados O sistema exibe a mensagem: MSG_05 EX03 Usurio no seleciona nenhum registro O sistema exibe a mensagem MSG_G8

3.2.1.7.1 ITE05 Agenda

Figura 11: ITE05 Agenda.

37 3.2.2 Diagrama de Estado

Figura 12: Diagrama de Estado.

38 3.2.3 Modelo Entidade Relacionamento MER

Figura 13: Modelo Entidade Relacionamento.

3.3 Vantagens percebidas na utilizao de padres de projeto

O resultado da utilizao dos Padres DAO (Data Access Object) e MVC (Model-View-Controller) que foram abordados no projeto, foi satisfatrio, pois diminuiu o acoplamento do sistema, ouve um grade reaproveitamento de cdigo, pois a camada de acesso a dados e a mesma para todo o sistema. Foi percebida tambm uma maior legibilidade do cdigo, pois o sistema foi todo dividido em camadas como foi proposto pelo padro MVC, por este motivo tambm se pode criar novos mdulos do sistema sem comprometer as outras partes j criadas no sistema.

39 4 CONCLUSO

Este trabalho se props a demonstrar como que a utilizao de padres de projetos e melhores prticas de desenvolvimento de software podem influenciar de forma positiva na qualidade do produto final, bem como alavancar benefcios arquiteturais, tais como: reutilizao de software, abstrao, separao de interesses, flexibilidade, extensibilidade, entre outros. Foi proposto mostrar como a orientao a objetos, a utilizao de um framework de persistncia a dados, uma plataforma de desenvolvimento junto com alguns padres de projeto, tcnicas para a documentao e levantamento de requisitos pode trazer melhores resultados no que tange ao desenvolvimento do software e, torna-se possvel a obteno dos principais requisitos desejados na aplicao. A implementao da proposta neste trabalho permitiu que fosse atingido o objetivo de aplicar na pratica os pontos principais propostos no trabalho. O resultado deste trabalho foi satisfatrio, pois foi vencedor de um programa realizado em conjunto com a universidade PUC e empresa Microsoft, o S2B Student to Business, que tem o objetivo de formar novos desenvolvedores, apresentando o que a de novo no mercado voltado para o desenvolvimento de software

40 5 REFERNCIAS BIBLIOGRFICAS Aplicao do Padro Data Access Object (DAO) em Projetos desenvolvidos com Delphi - Marcelo Sardagna, Adilson Vahldick - Universidade Regional de Blumenau (FURB) Disponvel em: < http://www.inf.ufsc.br/erbd2008/artigos/2.pdf>. Acesso em: 16 nov. 2010. Artigo .NET Magazine 76 - Design Patterns na prtica, 2010. Artigo .NET Magazine 72 - Design Patterns Strategy e Flyweight, 2010. COAD, Peter; YOURDON, Edward. Anlise Baseada em Objetos. So Paulo: Editora Campus, 1992. C.J. DATE. Introduo a Sistema de Banco de Dados. So Paulo: Editora Campus, 2000. ECKSTEIN, R. Java SE Application Design With MVC. Disponvel em: <http://java.sun.com/developer/technicalArticles/javase/mvc>. Acesso em: 10 nov. de 2010. FOWLER, Martin; BECK, Kent; BRANT, John; OPDYKE, William; ROBERTS, Don. Refactoring: Improving The Design Of Existing Cod. Importado: Editora Addison Wesley Longman, 1999. GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Design Patterns: Elements Of Reusable Object-Oriented Software. Importado: Editora: Addison Wesley, 1995 GILLEANES, T. A. Guedes. UML Uma Abordagem Prtica. 3. edio. So Paulo: Editora Novatec, 2008. METSKER, Steven John. Padres de projetos em Java. Porto Alegre: Editora: Bookman, 2004. ROBINSON, Simon. K. Scott Allen; CORNES, Ollie; GLYNN, Jay; GREENVOSS, Zach; HARVEY, Burton; NEGAL, Christian; SKINNER, Morgan; WATSON, Karli. C# Programando. So Paulo: Editora Person Education, 2004. RUMBAUGH, James; BOOCH, Grady; JACOBSON, Ivar. Uml - Guia do Usurio - Traduo da 2 Edio. So Paulo: Editora Campus, 2000. SHARP, John. Microsoft Visual C# 2008 - Passo a Passo. So Paulo: Editora Artmed, 2008. SHEPHERD, George. Microsoft ASP.NET 3.5: Passo a Passo Traduo Altair Caldas Dias de Moraes. Porto Alegre: Editora Bookman, 2009

41

SANTOS, Rafael. Introduo programao orientada a objetos usando Java. 7 reimpresso. So Paulo: Editora Elsevier, 2003. SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistemas de Banco de Dados. So Paulo: Editora Pearson Education do Brasil, 1999. <http://www.ebah.com.br/conceitos-basicos-mvc-pdf-a21097.html>. Acesso em: 10 nov. de 2010. Sun. (2007) Core J2EE patterns: data access object. Disponvel em: <http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.ht ml>. Acesso em: 16 nov. 2010.