Sem resumo de edição |
|||
| (10 revisões intermediárias por um outro usuário não estão sendo mostradas) | |||
| Linha 1: | Linha 1: | ||
== '''Breve descrição'''== | == '''Breve descrição'''== | ||
| Linha 11: | Linha 5: | ||
Design de software é o processo de implementação de soluções de software para um ou mais conjunto de problemas. Uma das partes importantes do design de software é a análise de requisitos de software ('''SRA''' - Software Requirements Analysis). É uma parte do processo de desenvolvimento que lista as especificações utilizadas em engenharia de software. Se o software é "semi-automático" ou centrado no usuário, o design de software pode envolver a experiência de usuário ('''UX''' - User experience), produzindo um "''history board''" para ajudar a determinar suas especificações. Se o software é totalmente automatizado (ou seja, nenhum usuário ou interface de usuário), um design de software pode ser tão simples como um fluxograma ou um texto descrevendo uma seqüência planejada de eventos. Existem também métodos semi-padrão, como Unified Modeling Language ('''UML''')e conceitos de modelagem Fundamentais . Em ambos os casos, alguns documentação do plano é normalmente o produto do cartão. Além disso, um projeto de software pode ser independente de plataforma ou específico de plataforma, dependendo da disponibilidade da tecnologia utilizada para o design. | Design de software é o processo de implementação de soluções de software para um ou mais conjunto de problemas. Uma das partes importantes do design de software é a análise de requisitos de software ('''SRA''' - Software Requirements Analysis). É uma parte do processo de desenvolvimento que lista as especificações utilizadas em engenharia de software. Se o software é "semi-automático" ou centrado no usuário, o design de software pode envolver a experiência de usuário ('''UX''' - User experience), produzindo um "''history board''" para ajudar a determinar suas especificações. Se o software é totalmente automatizado (ou seja, nenhum usuário ou interface de usuário), um design de software pode ser tão simples como um fluxograma ou um texto descrevendo uma seqüência planejada de eventos. Existem também métodos semi-padrão, como Unified Modeling Language ('''UML''')e conceitos de modelagem Fundamentais . Em ambos os casos, alguns documentação do plano é normalmente o produto do cartão. Além disso, um projeto de software pode ser independente de plataforma ou específico de plataforma, dependendo da disponibilidade da tecnologia utilizada para o design. | ||
*''"o design de software é o ato de determinar a experiência do usuário com um pedaço de software. Não tem nada a ver sobre como o código opera internamente ou se ele é grande ou pequeno. A tarefa do designer é especificar de forma completa e não ambígua a experiência global do usuário''". [''David Liddle, Design of The Conceptual Model''] - Disponível em:<http://hci.stanford.edu/publications/bds/2-liddle.html>Acesso em:<maio/2014> | |||
*''"o design de software é o ato de determinar a experiência do usuário com um pedaço de software. Não tem nada a ver sobre como o código opera internamente ou se ele é grande ou pequeno. A tarefa do designer é especificar de forma completa e não ambígua a experiência global do usuário''".'' ''[''David Liddle, Design of The Conceptual Model''] - Disponível em:<http://hci.stanford.edu/publications/bds/2-liddle.html>Acesso em:<maio/2014> | |||
Projeto de software pode ser considerado como a criação de uma solução para um problema, através de capacidades disponíveis. A principal diferença entre análise e projeto de software é que a saída de um software de análise consiste de pequenos problemas a serem resolvidos. Além disso, a análise não deve ser muito diferente, mesmo se projetada por diferentes membros de uma equipe ou grupo. O projeto se concentra nos recursos, e podem haver vários projetos para o mesmo problema, dependendo do ambiente em que a solução será hospedada. Eles podem ser sistemas de operações, páginas web, aplicações celulares ou até mesmo o novo paradigma de computação em nuvem. | Projeto de software pode ser considerado como a criação de uma solução para um problema, através de capacidades disponíveis. A principal diferença entre análise e projeto de software é que a saída de um software de análise consiste de pequenos problemas a serem resolvidos. Além disso, a análise não deve ser muito diferente, mesmo se projetada por diferentes membros de uma equipe ou grupo. O projeto se concentra nos recursos, e podem haver vários projetos para o mesmo problema, dependendo do ambiente em que a solução será hospedada. Eles podem ser sistemas de operações, páginas web, aplicações celulares ou até mesmo o novo paradigma de computação em nuvem. | ||
Ao projetar software, dois fatores importantes a serem considerados são a sua segurança e usabilidade. | Ao projetar software, dois fatores importantes a serem considerados são a sua segurança e usabilidade. | ||
== '''Conceitos Fundamentais'''== | == '''Conceitos Fundamentais'''== | ||
| Linha 37: | Linha 31: | ||
'''Estrutura de Dados''' - É uma representação da relação lógica entre os elementos de dados individuais. | '''Estrutura de Dados''' - É uma representação da relação lógica entre os elementos de dados individuais. | ||
'''Procedimento de Software''' - Incide sobre o processamento de cada módulo individualmente | '''Procedimento de Software''' - Incide sobre o processamento de cada módulo individualmente. | ||
== '''Objetivos específicos do Design'''== | == '''Objetivos específicos do Design'''== | ||
| Linha 44: | Linha 38: | ||
'''Acoplamento''' - O acoplamento é o grau de interconexão entre módulos. Quanto mais forte torna a implementação e a manutenção de um sistema mais difíceis, portanto o acoplamento deve ser minimizado, a fim de que mudanças não afetem todo o sistema diretamente. | '''Acoplamento''' - O acoplamento é o grau de interconexão entre módulos. Quanto mais forte torna a implementação e a manutenção de um sistema mais difíceis, portanto o acoplamento deve ser minimizado, a fim de que mudanças não afetem todo o sistema diretamente. | ||
'''Coesão''' - Do lado oposto do acoplamento, está a coesão que, se maximizada, tende a diminuir o acoplamento. A coesão trata de agrupar elementos totalmente indispensáveis (elementos do módulo tratados como peças de um quebra-cabeças) para o bom funcionamento de um módulo, sendo que quanto maior o grau de coesão maior legibilidade no sistema. | |||
'''Manutenibilidade''' - Corresponde ao grau de facilidade de manutenção (corretiva ou de aperfeiçoamento) do software. Essa facilidade pode ser dada através da boa aplicação dos conceitos "Ocultação de informações", "Acoplamento" e "Coesão". A eficiência pode ser deixada de lado quando em detrimento da manutenibilidade e economia, pois um sistema muito eficiente, pode ser muito complicado de ser modificar. | |||
'''Tamanho do módulo''' - Depende muito da linguagem utilizada (maior para Assembly, por exemplo e, menor para linguagens de alto nível). | |||
'''Abrangência do controle''' - Refere-se à quantidade de módulos imediatamente subordinados a um módulo gerenciador. É aconselhável que não seja praticado o "aninhamento" de vários módulos, pois isso torna o controle complexo, de difícil entendimento e com muitas dependências. | |||
'''Extensão do controle''' - Qualquer módulo afetado pelo resultado de uma decisão deve estar subordinado ao módulo que tomou a decisão. No entanto, a extensão ou efeito da sequência de decisões não deve ser tão profunda e nem deve considerar passagens desnecessárias de “flags” ou “switches” que aumentam o acoplamento entre os módulos. | |||
== Referências == | == Referências == | ||
Edição atual tal como às 23h01min de 5 de outubro de 2014
Breve descrição
Design de software geralmente envolve a resolução de problemas e planejamento de um software/solução. Isso inclui tanto a componente de baixo nível e projeto de algoritmos e, de alto nível, arquitetura e design.
Design de software é o processo de implementação de soluções de software para um ou mais conjunto de problemas. Uma das partes importantes do design de software é a análise de requisitos de software (SRA - Software Requirements Analysis). É uma parte do processo de desenvolvimento que lista as especificações utilizadas em engenharia de software. Se o software é "semi-automático" ou centrado no usuário, o design de software pode envolver a experiência de usuário (UX - User experience), produzindo um "history board" para ajudar a determinar suas especificações. Se o software é totalmente automatizado (ou seja, nenhum usuário ou interface de usuário), um design de software pode ser tão simples como um fluxograma ou um texto descrevendo uma seqüência planejada de eventos. Existem também métodos semi-padrão, como Unified Modeling Language (UML)e conceitos de modelagem Fundamentais . Em ambos os casos, alguns documentação do plano é normalmente o produto do cartão. Além disso, um projeto de software pode ser independente de plataforma ou específico de plataforma, dependendo da disponibilidade da tecnologia utilizada para o design.
- "o design de software é o ato de determinar a experiência do usuário com um pedaço de software. Não tem nada a ver sobre como o código opera internamente ou se ele é grande ou pequeno. A tarefa do designer é especificar de forma completa e não ambígua a experiência global do usuário". [David Liddle, Design of The Conceptual Model] - Disponível em:<http://hci.stanford.edu/publications/bds/2-liddle.html>Acesso em:<maio/2014>
Projeto de software pode ser considerado como a criação de uma solução para um problema, através de capacidades disponíveis. A principal diferença entre análise e projeto de software é que a saída de um software de análise consiste de pequenos problemas a serem resolvidos. Além disso, a análise não deve ser muito diferente, mesmo se projetada por diferentes membros de uma equipe ou grupo. O projeto se concentra nos recursos, e podem haver vários projetos para o mesmo problema, dependendo do ambiente em que a solução será hospedada. Eles podem ser sistemas de operações, páginas web, aplicações celulares ou até mesmo o novo paradigma de computação em nuvem.
Ao projetar software, dois fatores importantes a serem considerados são a sua segurança e usabilidade.
Conceitos Fundamentais
Abstração - Abstração é o processo ou resultado de generalização por redução do conteúdo da informação de um conceito ou um fenômeno observável, normalmente para reter apenas a informação que é relevante para um propósito particular. É algo muito útil em design de software, pois coloca o desenvolvedor em diferentes níveis, considerando a praticidade de uso, sem a necessidade de compreensão detalhada de como tudo foi concebido.
Refinamento - É o processo de elaboração. A hierarquia é desenvolvida pela decomposição de uma declaração macroscópica da função de forma gradual, até que instruções de linguagem de programação são atingidas. Em cada passo, uma ou mais instruções de um dado programa são decompostos em instruções mais detalhadas. Abstração e requinte são conceitos complementares.
Modularidade - a arquitetura do software é dividida em componentes chamados módulos, de modo que o bom funcionamento do sistema depende do bom funcionamento individual de cada módulo.
Arquitetura de Software - Compreende a estrutura hierárquica dos módulos (componentes de instruções procedimentais), podendo-se então tratar o software como um conjunto de "problemas", cada um com sua solução ou como um "problema" dependente de várias estruturas de dados e/ou soluções. Refere-se à estrutura geral do software e as formas em que essa estrutura fornece integridade conceitual para um sistema. A arquitetura de software vai render um bom retorno sobre o investimento com relação ao resultado desejado do projeto, por exemplo, em termos de desempenho, qualidade, prazos e custos.
Controlar Hierarquia - É importante para definir a organização dos componentes na estrutura do programa, de modo que fique clara a relação entre os módulos através do diagrama de estrutura, não sendo necessariamente uma sequência de decisões ou operações.
Divisória estrutural - A estrutura do programa pode ser dividido tanto horizontalmente e verticalmente. Partições horizontais definir ramos separados da hierarquia modular para cada função do programa principal. O particionamento vertical sugere que o controle e o trabalho devem ser distribuídos de cima para baixo na estrutura do programa.
Estrutura de Dados - É uma representação da relação lógica entre os elementos de dados individuais.
Procedimento de Software - Incide sobre o processamento de cada módulo individualmente.
Objetivos específicos do Design
Ocultação de informações - Os módulos devem ser especificados e concebidos de modo que as informações contidas dentro de um módulo é inacessível para outros módulos que não têm necessidade de tais informações.
Acoplamento - O acoplamento é o grau de interconexão entre módulos. Quanto mais forte torna a implementação e a manutenção de um sistema mais difíceis, portanto o acoplamento deve ser minimizado, a fim de que mudanças não afetem todo o sistema diretamente.
Coesão - Do lado oposto do acoplamento, está a coesão que, se maximizada, tende a diminuir o acoplamento. A coesão trata de agrupar elementos totalmente indispensáveis (elementos do módulo tratados como peças de um quebra-cabeças) para o bom funcionamento de um módulo, sendo que quanto maior o grau de coesão maior legibilidade no sistema.
Manutenibilidade - Corresponde ao grau de facilidade de manutenção (corretiva ou de aperfeiçoamento) do software. Essa facilidade pode ser dada através da boa aplicação dos conceitos "Ocultação de informações", "Acoplamento" e "Coesão". A eficiência pode ser deixada de lado quando em detrimento da manutenibilidade e economia, pois um sistema muito eficiente, pode ser muito complicado de ser modificar.
Tamanho do módulo - Depende muito da linguagem utilizada (maior para Assembly, por exemplo e, menor para linguagens de alto nível).
Abrangência do controle - Refere-se à quantidade de módulos imediatamente subordinados a um módulo gerenciador. É aconselhável que não seja praticado o "aninhamento" de vários módulos, pois isso torna o controle complexo, de difícil entendimento e com muitas dependências.
Extensão do controle - Qualquer módulo afetado pelo resultado de uma decisão deve estar subordinado ao módulo que tomou a decisão. No entanto, a extensão ou efeito da sequência de decisões não deve ser tão profunda e nem deve considerar passagens desnecessárias de “flags” ou “switches” que aumentam o acoplamento entre os módulos.