Artigo .net Magazine 61 - Construa uma Aplicação 100% - Parte 1

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (2)  (0)

Artigo da Revista .NET Magazine - Edição 61.

Esse artigo faz parte da revista .NET Magazine edição 61. Clique aqui para ler todos os artigos desta edição

 

imagem_pdf.jpg

 

Construa uma Aplicação 100% OO – Parte 1

Uma visão prática e realista do desenvolvimento de sistemas orientados a objetos

 

Introdução

“Programar é divertido, mas desenvolver sistemas com qualidade é difícil”. Essa frase denuncia a enorme diferença entre programar e realizar um completo processo de análise de sistemas, especificando do modo indelével como determinado problema deve ser solucionado, sem deixar de utilizar uma linguagem simples de comunicar, revisar, implementar e evoluir.

A orientação a objetos busca realizar esse grande feito. No entanto, para construir aplicativos verdadeiramente orientados a objetos é necessário muito mais do que simplesmente fazer uso de herança, polimorfismo, encapsulamento e abstração, os alicerces desse novo paradigma.

Veremos que a palavra-chave de todo o paradigma da orientação a objetos é abstração. A própria criação de um objeto é um exercício de abstração. Cada classe de negócios cria uma redoma de abstração em torno de suas funcionalidades e características. A arquitetura de software busca a abstração entre as camadas de apresentação, de negócios e de dados. O processo de análise de sistemas, incremental e espiralado, faz com que cada fase do projeto se mantenha abstraída das fases seguinte.

Neste artigo analisaremos uma Metodologia de Desenvolvimento de Sistemas Orientados a Objeto (MDS-OO) baseada nas tecnologias atualmente utilizadas nos principais projetos de software: Unified Software Development Process (Processo Unificado de Desenvolvimento de Software), ou simplesmente UP, e Unified Modeling Language (UML). Abordaremos desde a fase de concepção do projeto até a implantação, passando pelas fases de especificação, arquitetura e construção. Partindo da premissa de que o leitor conhece os conceitos básicos da UML (mesmo que minimamente), iniciaremos pelo estudo de alguns artefatos de negócios, caminhando até a construção de uma pequena aplicação de controle de utilização de equipamentos e outros recursos materiais, em ASP.Net com VB.Net e banco de dados padrão SQL, que servirá como base de estudos práticos dos aspectos abordados.

O artigo, assim como o desenvolvimento de um sistema, está dividido em partes. Nessa primeira parte do artigo, começaremos pela homogeneização dos conhecimentos com uma breve introdução às tecnologias adotadas e passaremos pelas fases de planejamento e concepção do projeto. Nas partes seguintes continuaremos navegando pelo processo de desenvolvimento, caminhando pelas demais fases do projeto até chegarmos a construção e implantação de nossa aplicação.

 

Projeto de Sistemas

A demanda para o desenvolvimento de um novo sistema de computador normalmente está originada na percepção de necessidades da área demandante, cliente do produto a ser desenvolvido. Essa necessidade tipicamente está baseada em uma ou mais das seguintes situações:

ûUma nova oportunidade de negócio, visando o aumento de receita da empresa;

ûUma demanda do mercado, visando atingir as necessidades dos clientes que podem ou não resultar em aumento de receita;

ûUma exigência de um cliente específico;

ûUma evolução tecnológica que permita reduzir custos e riscos ou agregar valor ao produto da empresa;

ûUma exigência legal.

 

É importante que tenhamos o senso de que é a área demandante (cliente) que tem a propriedade do produto a ser implantado e não a área de tecnologia ou de desenvolvimento de sistemas. É comum encontrarmos instituições onde se entende erradamente que os sistemas de computador são de propriedade da área de tecnologia. No processo de desenvolvimento, a área de TI é fornecedora de recursos e expertise, e responsável pela construção do sistema conforme definição do cliente, devendo atender às necessidades e expectativas do mesmo.

Essa divisão de responsabilidades, apesar de bastante natural, é significativa para o sucesso do empreendimento. Não deveria existir desenvolvimento de sistemas sem a formalização de um projeto de desenvolvimento, assim como não deveria existir um projeto de desenvolvimento sem um cliente responsável pelo produto a ser desenvolvido.

A criação de um novo sistema de computador contextualizado em um projeto de desenvolvimento de software garantirá a aplicação dos conhecimentos, habilidades e técnicas na elaboração de atividades que visem atingir um conjunto de objetivos pré-estabelecidos.

O corpo de conhecimentos de gerencia de projetos (PMBOK), compilado e publicado pelo PMI (Project Management Institute), define projeto como sendo “um empreendimento temporário com o objetivo de criar um produto o serviço único”.

 

Nota do DevMan

Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o Project Management Institute (PMI) é a principal associação mundial sem fins lucrativos em Gerenciamento de Projetos, atualmente com mais de 170.000 associados em todo o mundo.

 

Neste artigo faremos uso de técnicas de gestão de projeto e de modelagem de sistemas orientados a objetos na especificação e construção de um sistema aplicativo para controle dos recursos materiais de uma empresa fictícia, doravante denominada como Companhia ACME. Um recurso material pode ser uma sala de reunião, uma sala de vídeo conferência, um projetor, um notebook, um celular, um automóvel ou qualquer outro tipo de recurso que a empresa disponibilize para uso por seus funcionários, clientes e parceiros. O sistema deve possibilitar a manutenção do cadastro dos recursos materiais, assim como dos pedidos de utilização (com ou sem reserva prévia) dos mesmos.

A construção de um aplicativo real nos permitirá uma visão realística da adoção das técnicas de modelagem e uma melhor compreensão dos vários conceitos lógicos que serão abordados ao longo do estudo da MDS-OO. Concentraremo-nos na elaboração e construção de uma funcionalidade completa (iteração) - “Manter Cadastro de Recursos” - o que nos permitirá percorrer todas as disciplinas da metodologia de desenvolvimento.

 

Metodologia de Desenvolvimento de Sistemas Orientados a Objetos

Uma metodologia de desenvolvimento de sistemas reúne o conjunto de atividades necessárias à construção de softwares de qualidade, capazes de atender às necessidades e expectativas do usuário final, cliente do produto a ser desenvolvido. A MDS-OO é a referência a ser seguida pela equipe de desenvolvimento (gerentes de projeto, analistas de negócios, projetistas, arquitetos, administradores de banco de dados e codificadores) para os projetos de desenvolvimento ou manutenção de softwares concebidos no paradigma da orientação a objetos.

No mercado de projetos de software existem várias metodologias de desenvolvimento, concebidas no corpo de conhecimento da Engenharia de Software e que sempre objetivam aumentar a produtividade do processo de desenvolvimento e garantir a qualidade do software. Um padrão bastante discutido e difundido no mercado mundial é o Processo Unificado de Desenvolvimento de Sistemas (Unified Process), que usa a abordagem da orientação a objetos e é projetado e documentado utilizando a UML (Unified Modeling Language).

O Processo Unificado (UP) organiza o projeto em quatro fases, com ênfases específicas, que caracterizam os objetivos de um dado momento do projeto. As fases do projeto e suas respectivas ênfases estão relacionadas a seguir:

ûConcepção (Iniciação) – Ênfase no escopo do trabalho a ser realizado.

ûElaboração – Ênfase na arquitetura.

ûConstrução – Ênfase no desenvolvimento.

ûTransição – Ênfase na implantação.

 

Cada fase do projeto, por sua vez, está orientada para as disciplinas do processo de desenvolvimento e dos processos de apoio. As disciplinas do processo de desenvolvimento são Modelagem de Processos, Requisitos, Análise, Projeto (Design), Implementação, Teste e Implantação. As disciplinas dos processos de apoio são Gerencia de Configuração e Mudança, Gerenciamento do Projeto e Ambiente. A Figura 1 apresenta o famoso “Gráfico de Baleias” com o relacionamento entre as fases, as disciplinas e as iterações de um projeto de sistema.

 

Figura 1. Gráfico de Baleias

 

Nossa metodologia de desenvolvimento estará baseada no modelo de desenvolvimento iterativo e incremental, o que significa que o sistema será implementado em versões sequenciadas e executáveis continuamente integradas ao plano geral de arquitetura, de forma que cada nova versão incorpore aprimoramentos em relação às versões anteriores. Estabeleceremos assim um ciclo de desenvolvimento orientado às funcionalidades construídas e estruturado em iterações e disciplinas. Cada iteração e disciplina é responsável por gerar um conjunto de artefatos, que são os documentos de textos, diagramas e outros objetos de valor criados pela equipe de desenvolvimento e que visam documentar o sistema e subsidiar a construção e implantação do produto.

O projeto estará estruturado em iterações, sendo cada iteração responsável por entregar uma nova versão do sistema, com funcionalidades completas. As iterações estão associadas aos subprodutos ou processos elementares que compõem o sistema em desenvolvimento e serão relacionadas no Plano de Iterações do Projeto.

 

Nota do DevMan

Segundo o Manual de Práticas de Contagem por Ponto de Função do IFPUG, versão 4.2.1, um processo elementar é a menor unidade de atividade significativa para o usuário, completa e que deixa o negócio da aplicação em um estado consistente. Um processo elementar também pode ser chamado de transação de negócio.

 

Cada iteração estará organizada por disciplinas, com pontos de controle e objetivos específicos a serem atingidos ao longo do desenvolvimento. A Tabela 1 apresenta as disciplinas de projeto e seus respectivos objetivos.

 

"

Disciplina

Objetivo

Modelagem do Negócio

Entender a estrutura e a dinâmica da organização e, em especial, do processo de negócio a ser suportado pela aplicação, entendendo os problemas atuais e identificando as possibilidades de melhorias.

Requisitos

Conceber os requisitos do sistema, definir casos de usos principais e especificar a arquitetura primária.

Análise e Projeto

Consolidar os requisitos, refinar a análise, detalhar os casos de uso, detalhar roteiros de testes e definir a arquitetura para a iteração especificada.

Implementação

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?