Prof.

Ralf Moura

Engloba um conjunto de princpios conceitos e prticas que levam ao desenvolvimento de um sistema ou produto de alta qualidade. O objetivo da Engenharia de Projeto produzir um modelo ou representao que exiba firmeza, comodidade e prazer. Para tanto um projetista precisa praticar a diversificao e depois a convergncia. Diversificao a aquisio de um repertrio de alternativas; A medida que isto ocorre, alternativas so consideradas e rejeitadas, convergindo para uma particular configurao de componentes e, assim, a criao do produto final.

Acontece normalmente aps a fase de anlise; Modelos necessrios para uma completa especificao do projeto:
Projeto Projeto Projeto Projeto de dados/classes; arquitetural; de interface; de componentes.

A importncia do projeto de software pode ser definida com uma nica palavra: Qualidade. O projeto serve de base para todos os passos de engenharia de software e de suporte de software que se seguem. Sem projeto, arrisca-se a construir um sistema instvel que falhar quando pequenas modificaes forem feitas;

Algumas caractersticas que servem de orientao para a avaliao de um bom projeto: Deve implementar todos os requisitos explcitos contidos no modelo de anlise e acomodar todos os requisitos implcitos desejados pelo cliente. Deve ser um guia legvel, compreensvel para aqueles que geram cdigo e para os que testam e, subseqentemente, do suporte ao software. Deve fornecer um quadro completo do software, focalizando os domnios de dados, funcional e comportamental sob uma perspectiva de implementao.

Para avaliarmos a qualidade de uma representao do projeto, precisamos estabelecer critrios tcnicos para um bom projeto:
Deve exibir uma arquitetura e padres reconhecidos; Deve ser modular; Deve conter representaes distintas de dados, arquitetura, interfaces e componentes;

Deve levar estruturas de dados adequadas s classes a ser implementadas e baseadas em padres de dados reconhecveis; Deve levar componentes que exibam caractersticas funcionais independentes. Deve levar a interfaces que reduzam a complexidade das conexes entre componentes e com ambiente externo Deve ser derivado por meio de um mtodo passvel de repetio que seja conduzido pela informao obtida durante a anlise dos requisitos de software; Deve ser representado usando uma notao que efetivamente comunique seu significado.

Abstrao; Arquitetura; Padres; Modularidade; Ocultamento de informao; Independncia Funcional; Refinamento; Refabricao.

Refinamento das classes de anlise; Classes de Projeto

Classes Classes Classes Classes Classes de interface com o usurio; de domnio de negcio; de processo; persistentes; de sistema.

Devem ser bem formadas e devem possuir as quatro caractersticas descritas abaixo:
Completeza e suficincia: encapsulamento completo de todos os atributos e mtodos; Primitivismo: No deve fornecer formas diferentes para se realizar uma mesma funo; Alta Coeso: Deve ter um conjunto de responsabilidades pequeno e enfocado; Baixo acoplamento: Classes colaboram entre si. necessrio que a colaborao seja restrita a um nvel mnimo aceitvel.

Elementos de Projeto de Dados: modelos de dados:

refinado durante o projeto.

Elementos de Projeto de Arquitetural: O projeto arquitetural nos d uma viso geral do software.

Elementos de Projeto da Interface: o detalhamento de todos os elementos que compe o projeto arquitetural e dividida em trs importantes elementos: Interface com o usurio (UI): Incorpora elementos estticos (cor, grficos, layout) e elementos tcnicos como padres de UI e elementos reusveis. Interfaces externas: Incorpora a conectividade do sistemas sendo desenvolvido com outros sistemas existentes e devem incorporar: verificao de erros e restries de segurana. Interfaces internas: Incorpora os mecanismos de conectividade e troca de mensagens entre os vrios elementos do sistema.

Elementos de Projeto em Nvel de Componente: Detalha completamente os detalhes internos de cada componente do sistema.

Elementos de Projeto em Nvel de Implantao: Indicam como a funcionalidade e os subsistemas do software sero alocados no ambiente computacional fsico que vai apoiar o software.

Deve-se procurar sempre a oportunidade de se reutilizar padres existentes em vez de criar outros.

Padres arquiteturais: Definem a estrutura global do software, indicam o relacionamento entre subsistemas e componentes do software; Padres de Projeto (Design Pattern): Atendem a um elemento especfico de projeto tal como agregao de componentes, relacionamento, etc... Padres de cdigo: Padres que padronizam formas de codificao e de algoritmos.

Frameworks: Miniarquiteturas reusveis que fornece a estrutura e comportamento genrico para uma famlia de abstrao de software. Como exemplo podemos citar alguns frameworks como: J2EE, Struts, Hibernate. Design Patterns: descrevem solues para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Exemplos: MVC e Singleton.

Design Pattern so mais abstratos que framework; Um framework inclui cdigo, diferentemente de um design pattern; Um framework pode conter vrios design patterns, mas o contrrio nunca ocorrer; Frameworks sempre tero um domnio de aplicao particular, enquanto design patterns no ditam uma arquitetura de aplicao particular ;

Existe uma maior facilidade para a deteco de erros, visto que frameworks so peas mais concisas de software. Podemos nos concentrar mais com a abstrao de solues do problema que estamos tratando. Torna mais eficiente a resoluo dos problemas. Como todos os itens acima ocasionam uma maior produtividade, podemos garantir que tambm teremos um maior lucro, pois teremos uma antecipao da entrega, e uma maior satisfao dos clientes.