.NET - Implementando Soluções OOP

.NET - Implementando Soluções OOP - I

Programar é fácil desenvolver software de qualidade é uma arte.

Com o crescente aumento da demanda e da complexidade envolvida no processo de desenvolvimento de software o conhecer os objetivos e os conceitos atuais usados no ciclo de vida de desenvolvimento de software tornou-se algo obrigatório e necessário a todo o desenvolvedor que pretende atuar com eficácia e qualidade.

A maioria dos projetos de software com os quais você irá se envolver, como desenvolvedor de software de negócios corporativo, será uma equipe onde atuam diversos desenvolvedores e gerentes com os mais variados perfis e papeis no processo de desenvolvimento de software.

Como integrante de uma equipe corporativa, você será solicitado a transformar os documentos do projeto de software em código da aplicação real. Além disso, como o desenho de programas orientados a objetos é um processo recursivo , os dependem do feedback dos desenvolvedores de software para refinar e modificar o projeto do programa.

A medida que você ganhar experiência no desenvolvimento de sistemas de software orientado a objetos, você pode até ser convidado para assistir a reuniões de projeto e contribuir para o processo. Portanto, como um desenvolvedor de software, você deve estar familiarizado com o propósito e a estrutura dos diferentes documentos de um projeto, bem como ter algum conhecimento de como esses documentos são desenvolvidos.

Neste artigo eu apresento alguns dos documentos mais usados para projetar os aspectos estáticos de o sistema. Para ajudar a compreender estes documentos, este artigo inclui algumas atividades práticas com base em uma estudo de caso limitado.

Dessa forma meu objetivo neste artigo é apresentar:

Os objetivos de um projeto de software;
Os fundamentos da UML - Unified Modeling Language;
O objetivo da especificação de requisitos de software;
Como os diagramas de caso de uso modelam os serviços que o sistema irá proporcionar;
Como os diagramas de classe modelam as classes de objetos que precisam ser desenvolvidas;

Pode parecer uma tarefa árdua mas acredite que com um pouco de persistência e prática ela será facilmente assimilada capacitando você a aplicar os conceitos no seu dia a dia de desenvolvedor.

Os objetivos de um projeto de software

Uma abordagem bem organizada para um projeto de sistemas é essencial quando estamos desenvolvendo programas orientados a objetos modernos e de nível empresarial.

A fase de projeto é uma das mais importantes no ciclo de desenvolvimento de software, e você pode monitorar muitos dos problemas associados com projetos de software a projetos pobres e falhos com uma comunicação inadequada entre os desenvolvedores e consumidores do sistema.

Infelizmente, muitos programadores e gerentes não gostam de se envolver nos aspectos do projeto do sistema. Para eles todo tempo que seja não seja gasto com a criação de código é algo improdutivo.

Para piorar a situação, os consumidores passaram a ser mais exigentes oque casou um aumento na complexidade do projeto de software e uma diminuição do seu tempo de ciclo de desenvolvimento. Além disso o produto de software passou a ter uma vida mais curta.

Assim, para cumprir prazos irrealistas e o escopo do projeto os desenvolvedores tendem a relegar a tarefa de planejar a fase do projeto de software a segundo plano, o que é altamente improdutivo e vai acabar afetando a qualidade final do produto.

Gastar tempo com a fase de projeto traz os seguintes benefícios:

Proporciona uma oportunidade para rever o processo de negócios atuais e corrigir ineficiências ou falhas descobertas;
Educa os clientes/consumidores sobre a forma como o processo de desenvolvimento de software ocorre;
Incorpora os clientes/consumidores como parceiros neste processo;
Cria um escopo de projeto e prazo realistas para a conclusão do projeto;
Fornece uma base para determinar os requisitos de teste de software;
Reduz o custo e o tempo necessários para implementar a solução de software;

Nota: Uma boa analogia com um projeto de software é o processo de construção de uma casa. Você não esperaria que o construtor comeceçasse a trabalhar na casa sem ter o projeto do arquiteto. Você
também espera que o arquiteto possa conversar com você sobre o projeto da casa antes de definir mais detalhes. É trabalho do arquiteto conversar com você sobre o projeto e as funcionalidade que você quer na casa e converter seus pedidos com os planos que o construtor usa para construir a casa. Um bom arquiteto também deve orientá-lo sobre características são razoáveis para o seu orçamento e quanto ao cronograma previsto.

Compreendendo a UML

Para desenvolver com êxito um projeto de software orientado a objetos você precisa seguir uma metodologia de projeto que seja comprovada. Uma das metodologias de projeto mais comuns usadas para projetos orientados a objeto atualmente é a UML - Unified Modeling Language.

Para trabalhar para ajudar na criação dos diagramas da UML você pode usar uma das seguintes ferramentas gratuitas:

A UML foi desenvolvida no início dos anos 80 como uma resposta à necessidade de se ter um padrão sistemático de modelagem de projeto de software orientado a objetos. Ela consiste de uma série de modelos textuais e gráficos da solução proposta. Estes modelos definem o escopo do sistema, os componentes do sistema do usuário, interação com o sistema e como os componentes do sistema interagem uns com os outros para implementar as funcionalidades do sistema.

Documento de Requistos do Sistema(DRS): Uma descrição textual de todos os requisitos e do escopo do sistema;
Caso de Uso: Uma descrição textual/gráfica de como o sistema irá se comportar a partir da perspectiva do usuário. Os usuários podem ser sistemas humanos ou outros sistemas;
Diagrama de Classe: Um modelo visual dos objetos que serão usados para construir o sistema;
Diagrama de Seqüência: Um modelo da seqüência de interação com objetos quando o programa executa. A ênfase é colocada na ordem das interações e como elas procedem ao longo do tempo;
Diagrama de Colaboração: Uma visão de como os objetos são organizados para trabalharem juntos durante a execução do programa. A ênfase é colocada sobre as comunicações que ocorrem entre os objetos;
Diagrama de Atividades: Uma representação visual do fluxo de execução de um processo ou operação;

Definindo o DRS

O propósito do DRS é:

Definir os requisitos funcionais do sistema.
Identificar os limites do sistema.
Identificar os usuários do sistema.
Descrever as interações entre o sistema e os usuários externos.
Estabelecer uma linguagem comum entre o cliente e a equipe do programa para descrição do sistema.
Fornecer a base para a modelagem de casos de uso.

Para produzir o DRS, você deve entrevistar os empresários/gerentes/funcionários e os usuários finais do sistema. O objetivo das entrevistas é documentar claramente os processos de negócios envolvidos e estabelecer o escopo do sistema.(o que deve ser feito)

O resultado deste processo é um documento formal (o DRS), detalhando os requisitos funcionais do sistema. Um documento formal ajuda a garantir um acordo entre os clientes e os desenvolvedores. O DRS também fornece uma base para resolver quaisquer divergências sobre escopo do sistema percebida conforme o desenvolvimento avança.

Como exemplo, suponha que os proprietários de uma pequena companhia aérea deseja que os clientes possam visualizar as informações de vôo e também reservar bilhetes para vôos que usando um sistema de registro na internet. Depois de entrevistar o pessoal que conhece o negócio (gerentes e funcionários da empresa) o especialista em requisitos de software cria um esboço de um documento listando os requisitos funcionais do sistema:

Usuários não registrados na web podem navegar até o site para visualizar as informações de vôo, mas eles não podem reservar voos;
Novos clientes que desejam reservar voos devem preencher um formulário de inscrição fornecendo o seu nome, endereço, nome da empresa, número de telefone e e-mail;
Um cliente é classificado como cliente de varejo ou cliente corporativo;
Os clientes podem pesquisar voos com base no destino e na origem;
Os clientes podem reservar voos, indicando o número do vôo e o número de assentos solicitados;
O sistema envia uma confirmação aos clientes via e-mail quando o vôo é reservado;
Os clientes corporativos recebem créditos de milhas de viagem quando realizam reservas em nome da empresa;
As Milhas de viagem são utilizadas para desconto em compras futuras;
As reservas de bilhetes podem ser canceladas com até uma semana de antecedência para um reembolso de 80%;
Os agentes de viagem podem visualizar e atualizar informações de vôo;

Temos acima um documento de especificação de requisitos (DRS) que embora parcial lhe mostra como usar declarações suscintas para definir o escopo do sistema.

O documento descreve as funcionalidades do sistema como vistas pelos usuários e identifica as entidades externas que irão usar o sistema. É importante notar que o SRS não contém referências aos requisitos técnicos do sistema ou requisitos. Uma vez criado o DRS os requisitos funcionais que ele contém são transformados em uma série de diagramas de caso uso.

Uma introdução aos casos de uso

Os casos de uso descrevem com entidades externas vão utilizar o sistema. Essas entidades externas podem ser pessoas ou outros sistemas, e são chamados de atores na terminologia UML A descrição enfatiza a visão do usuário do sistema e a interação entre o usuário e o sistema. Os casos de uso auxiliam a determinar o escopo e as fronteiras do sistema e são usados na forma de diagramas com uma descrição textual da interação realizada.

A figura 1 abaixo mostra um diagrama genérico que consiste de dois atores representados por duas figuras (bonecos) e um rótulo que indica o nome do ator, um retângulo que representa o sistema e os casos de uso representado por elipses, e um rótulo que representa o nome do caso de uso, inseridas nos limites do sistema:

Fig. 1 - Diagrama de Caso de uso genérico com dois atores e 3 casos de uso

Os casos de uso são gerados a partir do documento de requisitos do sistema (DRS) e um ator é qualquer entidade externa que interage com o sistema. Um ator pode ser um usuário humano (por exemplo, um funcionário), outro sistema de software (Ex: um sistema de cobrança), ou um dispositivo de interface (por exemplo, uma sonda de temperatura). Cada interação que ocorre entre um ator e o sistema é modelado como um caso de uso.

O caso de uso de exemplo mostrado na Figura 2 foi desenvolvido para a aplicação reserva de voo introduzido na seção anterior. Ele mostra o diagrama de caso de uso para o requisito: Os clientes podem pesquisar voos com base no destino e na origem;

Fig 2 - Caso de uso - Consultar informações de Voos

Junto com a representação gráfica do caso de uso, muitos designers e desenvolvedores de software acham útil fornecer uma descrição textual do caso de uso. A descrição textual deve ser sucinta e focado no que está acontecendo e não em como ela está ocorrendo. Às vezes, quaisquer pré-requisitos ou pós-condições associadas com o caso de uso também são identificados. O seguinte texto descreve o diagrama de caso de uso mostrado na Figura 2:

Descrição: Este caso de uso tem início quando um cliente visualiza a página de informação de voo. O cliente entra na busca de informações de vôo. Após submeter o pedido de busca, o cliente vê uma lista de voos que correspondem aos critérios de pesquisa;
Pré-requisitos: Nenhum;
Pós-condições: O cliente tem a oportunidade de entrar e avançar para a página reserva de voo;

Vejamos outro exemplo para o caso de uso Reservar assento na figura 3:

Fig 3 - Diagrama de caso de uso - Reservar Assento

O seguinte texto descreve ainda o diagrama de caso de uso mostrado na Figura 3:

Descrição: Este caso de uso começa quando o cliente informa o número de voo e indica os lugares solicitados. Depois que o cliente envia a solicitação, alguma informações de confirmação é exibida.
Pré-condições: O cliente localizou a informação de voo(localizador). O cliente esta conectado no sistema e esta no modo de visualização de tela de reserva de voo;
Pós-condições: É enviado um email de confirmação ao cliente indicando o vôo e os detalhes e as condições de cancelamento;

Como você pode ver na Figura 3, podem existir certas relações entre os casos de uso.

O caso de uso Reservar Assento inclui (ou usa) o caso de uso Consultar Informações de voos. Esta relação é útil porque você pode usar o caso de uso Consultar Informações de voos de forma independente do caso de uso de Reservar Voo. Isso é chamado de inclusão. No entanto você não pode usar o caso de uso Reservar Assento independentemente do caso de uso Consultar Informações de voos.

Obs: Neste caso O caso de uso Consultar Informações de Voos é essencial para o comportamento do caso de uso Reservar Assento

Outro relacionamento existente entre os casos de uso é a extensão. Você pode ter um caso de uso geral que é a base para outros casos de uso onde o caso de uso base é estendido por outros casos de uso. Por exemplo, você pode ter um caso de uso Registrar Clientes que descreve o processo central de cadastrar clientes.

Você poderia, então, desenvolver os casos de uso Registrar Cliente Corporativo e Registro Clientes Varejo que estendem o caso de uso base. A diferença entre extensão e de inclusão é que na extensão o caso de uso base não é usado por conta própria (O caso de uso base pode ser executado mesmo sem a extensão).

A Figura 4 mostra um exemplo de extensão entre casos de uso:

Fig 4 - Exemplo de extensão em casos de uso

Um erro comum no desenvolvimento de casos de uso é incluir ações iniciadas pelo próprio sistema. A ênfase dos casos de uso é na interação entre entidades externas e o sistema e não do próprio sistema.

Outro erro comum é incluir uma descrição dos requisitos técnicos do sistema. Lembre-se que o foco dos casos de uso não esta em como o sistema irá executar as funções, mas sim sobre quais funcões precisam ser incorporadas ao sistema do ponto de vista do usuário.

Depois de ter desenvolvido os casos de uso do sistema, você pode começar a identificar os objetos internos do sistema que irão realizar os requisitos funcionais do sistema. Você pode fazer isso através do uso diagrama de classes.

Apresentando o Diagrama de classes

Os conceitos de classes e objetos são fundamentais para a OOP.

Um objeto é uma estrutura para incorporação de dados e dos procedimentos para trabalhar com os dados. Esses objetos implementam a funcionalidade de um programa orientado a objetos.

Pense em uma classe como um modelo para o objeto. Uma classe define a estrutura e os métodos que os objetos irão conter com base no tipo de classe.

Os desenvolvedores identificam uma lista potencial de classes a serem desenvolvidas a partir do DRS e do diagrama de casos. Uma maneira de identificar as classes é olhando para os substantivos nas frases do documento DRS e nas descrições do caso de uso.

Se você olhar a documentação que usamos para o aplicativo de reservas da companhia aérea, você pode começar a identificar as classes que compõem o sistema. Por exemplo, você pode desenvolver uma classe de clientes para trabalhar com os dados do cliente e uma classe de vôo para trabalhar com os dados dos vôos.

Uma classe é responsável pela gestão de dados. Ao definir a estrutura de classes, você deve determinar por quais dados a classe é responsável. Os atributos de classe definem esta informação.

Por exemplo, a classe Voo terá atributos para identificar o número do vôo, horário de partida e data, duração do voo, destino, capacidade e assentos disponíveis.

A estrutura de classe também deve definir as operações que serão executadas nos dados. Um exemplo de uma operação pela qual a classe Voo é responsável é estar atualizando os assentos disponíveis quando um assento for reservado.

Um diagrama de classe pode ajudar a visualizar os atributos e operações de uma classe. Figura 5 é um exemplo do diagrama de classes para a classe Voo usada no exemplo do sistema de reserva de vôos.

Fig 5 - Diagrama de Classe Voo

Um retângulo dividido em três seções representa a classe.

A seção superior do retângulo mostra o nome do classe;
A seção do meio lista os atributos da classe;
A última parte apresenta as operações realizada pela classe;

Relacionamento entre classes

Os objetos tem relações entre eles: um professor ministra uma disciplina para alunos numa sala, um cliente faz uma reserva de alguns lugares para uma data, etc. Essas relações são representadas também no diagrama de classe. [Nicolas Anquetil]

A UML reconhece três tipos mais importantes de relações: dependência, associação e generalização (ou herança).

Geralmente as classes não estão sós e se relacionam entre si. O relacionamento e a comunicação entre as classes definem responsabilidades , temos 3 tipos :

Associações : Agregação e composição
Generalização (herança)
Dependências

As representações usam a seguinte notação :

Associação : São relacionamentos estruturais entre instâncias e especificam que objetos de uma classe estão ligados a objetos de outras classes. Podemos ter associação uniária , binária , etc.

A associação pode existir entre classes ou entre objetos. Uma associação entre a classe Professor e a classe Disciplina (um professor ministra uma disciplina) significa que uma instância de Professor (um professor específico) vai ter uma associação com uma instância de Disciplina. Esta relação significa que as instâncias das classes são conectadas, seja fisicamente ou conceitualmente.[Nicolas Anquetil]
Dependência - São relacionamentos de utilização no qual uma mudança na especificação de um elemento pode alterar a especificação do elemento dependente. A dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe.

Generalização (herança : simples ou composta) - Relacionamento entre um elemento mais geral e um mais específico. Onde o elemento mais específico herda as propriedades e métodos do elemento mais geral. A relação de generalização também é conhecida como herança no modelo a objetos. Como a relação de dependência, ela existe só entre as classes. Um objeto particular não é um caso geral de um outro objeto, só conceitos (classes no modelo a objetos) são generalização de outros conceitos.
Agregação Regular - tipo de associação ( é parte de , todo/parte) onde o objeto parte é um atributo do todo ; onde os objetos partes somente são criados se o todo ao qual estão agregados seja criado. Pedidos é composto por itens de pedidos.

Composição - Relacionamento entre um elemento ( o todo) e outros elementos (as partes) onde as parte só podem pertencer ao todo e são criadas e destruídas com ele.

O diagrama de de classes lista todos os conceitos do domínio que serão implementados no sistema e as relações entre os conceitos. Ele é muito importante pois define a estrutura do sistema a desenvolver.

Um possível diagrama de classes para o nosso exemplo de aplicação para reserva de vôos pode ser vista na figura 6:

Fig 6 - Diagrama de classes para reserva de vôos

O diagrama de classes acima inclui as classes, atributos e relacionamentos que foram identificados para o sistema.

Com essa pequena introdução você foi apresentado aos objetivos do processo de projeto orientado a objetos e UML, onde mostramos alguns dos documentos de projeto e diagramas produzidos utilizando a UML. Estes incluem :

O DRS, que define o escopo do sistema;
A utilização de diagramas de caso uso, que definem os limites do sistema e identificam as entidades externas que irão utilizar o sistema;
E os diagramas de classe, que é o modelo da estrutura das classes que serão desenvolvidas para implementar o sistema;

Na continuação deste artigo pretendo mostrar como realizar a modelagem da interação entre os objetos: .NET - Implementando Soluções OOP II

"Porque todos pecaram e destituídos estão da Glória de Deus; Sendo justificados gratuitamente pela sua graça, pela redenção que há em Cristo Jesus." Rom. 3:23-24

Referências:

José Carlos Macoratti