================ «« FAVOR NAO RETIRAR ESSE CABEÇALHO »» ================

Responsável: jackson.pires@gmail.com, igoroliveiracosta@gmail.com
Revisor: fulano de tal / xxx@xxxx.com
Revisado?: não - xxx@xxx.com

================ «« FAVOR NAO RETIRAR ESSE CABEÇALHO »» ================

* DESIGN DE SOFTWARE
o ACRÔNIMOS
+ Responsável : jackson.pires@gmail.com
+ Revisão: não revisado
+ ADL - Descrição de Arquitetura de Linguagens (Architecture Description Languages)
+ CRC - Cartão de Colaboradores Responsáveis (Class Responsibility Collaborator card)
+ ERD - Diagrama Entidade Relacionamento (Entity-Relationship Diagram)
+ IDL - Descrição de Linguagem de Interface (Interface Description Language)
+ DFD - Diagrama de Fluxo de Dados (Data Flow Diagram)
+ PDL - Linguagem de Pseudo-Código e Design de Programa (Pseudo-Code and Program Design Language)
+ CBD - Componente baseado em Desing (Component-Based design)
o INTRODUÇÃO
+ Responsável : jackson.pires@gmail.com
+ Revisão: não revisado
+ Design é definido no [IEEE610.12-90] de duas formas "o processo de definição da arquitetura, componentes, interfaces, e outras características de um sistema ou componente" e "o resultado do processo." Visto como um processo, o design de software é o ciclo de vida da engenharia de software no qual os requisitos de software são analisados para produzir uma descrição da estrutura interna dos software's que servirão como base de sua construção. Mais precisamente, o design de software (resultante) pode descrever a arquitetura de software - é isto, como o software é decomposto e organizado dentro dos componentes - e a interface entre estes componentes. Isso também descreve os componentes no nível de detalhe que permitem sua construção.
+ Design de Sofware emprega uma importante regra no desenvolvimento de software: isso permite engenheiros de software produzirem vários de modelos que formam um tipo de plano de solução para ser implementado. Nós podemos analisar e avaliar estes modelos para determinar se eles nos permitirão atender as diversas necessidades. Nós podemos também examinar e avaliar várias soluções alternativas e confrontá-las. Finalmente nós podemos usar os modelos resultantes para planejar as atividades do desenvolvimento subseqüente, em adição ao uso deles como entrada e ponto de começo da construção e teste.
+ Em uma listagem padrão do processo de ciclo de vida de software tal como IEEE/EIA 12207 Processos de Ciclo de Vida do Software [IEEE12207.0-96], design de software consiste em duas atividades que situa-se entre análises e requerimentos de software e construção de software:
# •Design de arquitetura de software (algumas vezes chamada design de alto nível - "Top-Level design): Descreve altos níveis de estrutura e organização de software's e identificação de componentes.
# •Design de software detalhado: Descreve cada componente suficientemente para permitir esta construção
+ A respeito do escopo da Área de Conhecimento do Design de Software (KA), a atual descrição KA não discute cada tópico do nome que contém a palavra "design." Na terminologia de Tom DeMarco's (DeM99), o KA discutido neste capítulo trata principalmente do D-Design (decomposição do design, mapeando o software dentro dos pedaços de componente). Entretanto, por conta dessa importância no campo de crescimento da arquitetura de software nós abordar o PF-Design (famíla de padrão de projeto, cujo o objetivo é estabelecer explorações comuns na família de software). Em contraste , o Design de Software KA não aborda I-Design (design da invenção, usualmente executada durante o processo de requisitos de software como o objetivo de conceitualizar e especificar o software para satisfazer descobertas necessárias e requisitos), desde este tópico deve ser considerado parte da especificação e análise de requisitos.
+ A descrição do Design de Software KA é relatada especificamente para os Requisitos do software, Construção do Software, Gerenciamento e Engenharia de Software, Qualidade do Software, e Disciplinas Relatadas com a Engenharia de Software.
o COLAPSO DOS TÓPICOS PARA DESIGN DE SOFTWARE
+ Responsável : jackson.pires@gmail.com
+ Revisão: não revisado
+ COLAPSO DOS TÓPICOS PARA DESIGN DE SOFTWARE
+ 1. Fundamentos do Design de Software
# Os conceitos, coções e terminologia introduzidas aqui formam uma linha base para entender o papel e o escopo do design de software.
+ 1.1 Conceitos Gerais de Design
# Software não é o único campo onde o desing está envolvido. No senso geral, nós podemos ver design como uma forma de resolver problemas. [Bud03:cl] Por exemplo, o conceito de um mau problema-um problema sem solução definifiva- é interessante em termos de entendimento dos limites do desifn. [Bud04:cl] Uma série de outras noções e conceitos são também de interesse para a compreensão de design no seu sentido geral: objetivos, restrições, alternativas, representações e soluções. [Smi93]
+ 1.2 Contexto do Design de Software
# Para entender o papel do design de software, é importante entender o contexto em que se enquadra o ciclo de vida da engenharia de software. Assim, é importane entender as maiores características das análises de requerimento de software vs. Design de software vs. Contrução de software vs. Teste de software.[IEEE12207.0-96]; Lis01:c11; Mar02; Pfl01:c2; Pre04:c2]
+ 1.3 Processo de Design de Software
# Design de software é geralmente considerado em dois passos: [Bas03; Dor02:v1c4s2; Fre83:I; IEEE12207.0-96]; Lis01:c13; Mar02:D]
* 1.3.1 Design Arquitetural
o Design Arquiterural descrece como o software é decomposto e organizado dentro de componentes (a arquitetura de software) [IEEEP1471-00]
* 1.3.2 Design Detalhado
o Design detalhado descreve o comportamento específico desses componentes
o A saída desse processo é um conjunto de modelos e artiefatos que guardam as maiores decisões que tenham sido tomadas.IEE1016-98; Lis01:c13; Pre04:c9
# 1.4 Técnicas Ativas
* De acordo com o Dicionário Inglês Oxford, um princípio é "uma verdade básica ou lei geral... que é usada como a base racioal ou guia de ação." Os princípios do desing de sofware, também são chamados de Técnicas Ativas ]Bus96], são noções chave consideradas fundamentais para muitas diferentes abordagens e conceitos de design de software. As técninas ativas são as seguintes: Bus96:c6; IEEE1016-98; Jal97:c5,c6; Lis01:c1,c3; Pfl01:c5; Pre04:c9
* 1.4.1 Abstração
o Abstração é "o processo de esquecer informações tais como coisas diferentes que podems ser tratadas como se elas fossem a mesma." [Lis01] No contesto de design de software, dois mecanismos chave de abstração são a parametrização e a especificação. Abstração por especificação guia-nos aos três maiores tipos de abstração: abstração procedural, abstração de dados, e controle (iteração) de abstração. Jal97:c5,c6; Lis01:c1,c2,c5,c6; Pre04:c1
* 1.4.2 Acoplamento e Coesão
o Acoplamento é definido como uma força de relacionamento entre módulos, enquanto coesão é definido por como os elementos que formam um módulo são relacionados. Jal97:c5; Pfl01:c5; Pre04:c9
* 1.4.3 Decomposição e modularização
o Decompor e Modularizar um grande software dentro de um pequeno número de partes únicas e independentes, usualmente com o objetivo de colocar diferentes funcionalidades ou responsabilidades em diferentes componentes. [Bas98:c6, Bus96:c6; Jal97 :c5; Pfl01:c5; Pre04:c9]
* 1.4.4 Encapsulamento / Ocultamento de Informação
o Encapsulamento / Ocultamento de Informação significa agrupar e separar em pacotes elementos e detalhes internos de uma abstração e fazendo esses detalhes inacessíveis. Bus96:c6; Jal97:c5; Pfl01:c5; Pre04:c9
* 1.4.5 Separação da interface e implementação
o Separação da interface e implementação envolve definir um componente para especificar uma interface, conhecer clientes, separando os detalhes de como os componente é ralizado.Bos00:c10; Lis01:c1,c9
* 1.4.6 Suficiência, completude e simplicidade
o Alcançar suficiência, completude e simplicidade siguinifica garantir que um componente de software capturam todas as características importantes de uma abstração, e nada mais. Lis01:c5
o SWEBOK_cap3_figura1.jpg
o 2. OS PONTOS CHAVE NO DESING DE SOFTWARE
+ Responsável : jackson.pires@gmail.com
+ Revisão: não revisado
+ Um certo número de pontos chave devem ser tratados na concepção de software. Alguns são preocupações de qualidade. Algumas preocupações são a qualidade que todos os softwares devem dirigir-por exemplo, performance. Outra questão importante é a forma de decompor, organizar e empacotar componentes de software. Isso é são fundamental que todas as obordagens endereçam isto em um caminho ou outro (veja o tópico 1.4 Ativando Técnicas na sub-área 6 Métodos e Estratégias de Design de Software). Em contraste a isto, outros pontos "enrtegam alguns aepectos do comportamento de software que não estão no domínio da aplicação, mas desejam endereçar algo no domínio so suporte." [Bos00] Tais pontos, desejam frequentemente cortar funcionalidades do sistema, referindo-se a aspectos: "aspectos não tendem a ser unidades de software funcionais decompostos, mas antes propriedades que afetam a perfprmance ou semântica dos componetes em caminhos sistêmicos.
# 2.1 Concorrência
* Como decompor o software em processos, tarefas e serviço e desejar eficiência, atomicidade, sincronização, e versões agendadas. Mesy97:c30; Pre04:c9
# 2.2 Controle e transporte dos Enventos
* Como organizar dados e controlar fluxos, como trasportar eventos reativos e temporais através de vários mecanismos tais como invocação implícita e call-back. Mey97:32; Pfl01:c5
# 2.3 Distribuição de Componentes
* Como distribuir o software baseado no hardware, como os componentes se comunicam, como um middleware pode ser usado para entregar sofware heterogêneo. Bos00:c5; Bus96:c2 Mar94:DD; Mey97:c30; Pre04:c30
# 2.4 Transporte de Exceção, Erro e Tolerância a falha
* Como previnir e torelar falhas e entregar condições excepicionais. Mey97:c12; Pfl01:c5
# 2.5 Interação e Apresentação
* Como estruturar e organizar interações com usuários e a apresentação da informação (por exemplo, separação da apresentação e lógica de negócios usando a abordagem Model-View-Controller).Bos00:c5;Bus96:c2; Lis01:c13; Mey97:c32. Isto pode ser notado que este tópico não é sobre detalhes de especificação da interface de usuários, deseja-se é que a tafera do desing de interface de usuário (uma parte do Software Ergonômico); veja as Disciplinas Relatadas da Engenharia de Software.
# 2.6 Persistência dos dados
* Como dados de longa vida podem ser transportados. Mey97:c31
o 3.ESTRUTURA E ARQUITETURA DE SOFTWARE
+ Responsável : adrianovidal@msn.com
+ Revisão: não revisado
+ No seu sentido estrito, uma arquitetura de software é "uma descrição dos subsistemas e de componentes de um sistema de software e as relações entre eles." (Bus96:c6) Arquitetura, assim, as tentativas de definir a estrutura interna.
+ - Segundo o Dicionário Inglês Oxford, "a forma como algo é construído ou organizado"- do resultando software. Durante meados da década de 1990, no entanto, arquitetura de software começou a emergi como uma mais ampla disciplina que envolve o estudo de estruturas e de arquiteturas de software de uma forma mais genérica [Sha96]. Isso deu origem a uma série de idéias interessantes sobre a concepção do software em diferentes níveis de abstração. Alguns desses conceitos podem ser úteis durante a concepção arquitetônica (por exemplo, estilo arquitetônico) de um software específico, bem como durante a sua concepção pormenorizada (por exemplo, a concepção de nível mais baixo padrões). Mas eles também podem ser úteis para a concepção de sistemas genéricos, levando à concepção de famílias de programas (também conhecidas como linhas de produtos). Curiosamente, a maior parte destes conceitos pode ser visto como tentativas de descrever, e deste modo o reuso, conhecimentos design genéricos.
+ 3.1 Estruturas arquitetônicas e Viewpoints
# Diferentes facetas de high-level de design de software podem e devem ser descritos e documentados. Estes aspectos são muitas vezes chamados views: "Uma view representa um parcial aspecto de uma arquitetura de software que mostra propriedades específicas de um sistema de software" [Bus96: c6]. Estas distintas views pertencem a distintas questões relacionadas com a design de software - por exemplo, a lógica view (que satisfaça as exigências funcionais) vs os processos view (questões de concurrency) vs físico views (questões de distribuição) vs o desenvolvimento view (o modo como o projeto é dividido em unidades de implementação). Outros autores usam diferentes terminologias, como comportamental vs funcional vs estruturais vs modelagem de dados view. Em resumo, um projeto de software é um multi-facetada artefato produzido pelo processo de design e geralmente composto de relativa independência e ortogonais vista. [Bas03: c2; Boo99: c31; Bud04: c5; Bus96: c6; IEEE1016-98; IEEE1471-00] estilos arquitetônicos (padrões de macroestruturas).
# Um estilo arquitetônico é "um conjunto de restrições sobre um arquitetura [que] define um conjunto ou família de arquiteturas que os satisfazem" [Bas03: c2]. Um estilo arquitetônico pode ser visto como uma meta-modelo que possa fornecer software de alto nível (high-level) para as organizações (a macro arquitetura). Diversos autores identificaram uma série de grandes estilos arquitetônicos. Boo99:c28; Bos00:c6; Bus96:c1,c6;Pfl01:c5
# Estrutura geral (por exemplo, camadas, tubos, e filtros, Blackboard);
# Sistemas Distribuídos (por exemplo, cliente-servidor, threetiers, broker);
# Sistemas Interativos (por exemplo, Model-View-Controller, Apresentação-Abstração-Controle);
# Adaptação de sistemas (por exemplo, micro-kernel, reflexão);
# Outros (por exemplo, lote, intérpretes, controle de processos, regras-base).
+ 3.2 Padrões de Design (padrões de micro arquitetura)
# Sucintamente descritos, um padrão é "uma solução comum para um problema comum em um determinado contexto." (Jac99) Embora estilos arquitetônicos possam ser vistos como padrões que descrevem o high-level de software das organizações (as suas macro arquiteturas), outros padrões de projeto pode ser usado para descrever em detalhes uma menor, mais nível local (a sua micro arquitetura). Boo99:c28; Bus96:c1;Mar02:DP
# Padrões Creational (por exemplo, construtor, fábrica, protótipo, e Singleton)
# Padrões estruturais (por exemplo, adaptador, ponte, compósito, decorador, fachada, flyweight, e proxy)
# Padrões comportamentais (por exemplo, comando, o intérprete, interação, mediador, memento, observador, estatal, estratégia, modelo, visitante).
+ 3.3 Famílias de programas e frameworks
# Uma possível abordagem para permitir a reutilização de design de softwares e de componentes é a concepção das famílias de software, também conhecidos como linhas de produtos de software. Isto pode ser feito através da identificação dos membros comuns dessas famílias, e usando componentes reutilizáveis e personalizáveis para levar em conta a variabilidade entre os membros da família. [Bos00:c7,c10; Bas98:c15; Pre04:c30]
# Na programação OO, uma chave relaciona noções do que é um framework: um subsistema parcialmente completo de software que pode ser estendido pelas instalações de plug-ins mais específicos (também conhecidos como hot spots).
o 4. ANÁLISE E EVOLUÇÃO DA QUALIDADE DE DESIGN DE SOFTWARE
+ Responsável : adrianovidal@msn.com
+ Revisão: não revisado
+ Esta secção inclui uma série de tópicos de qualidade e avaliação que estão especificamente relacionadas com a concepção do software. A maior parte é abrangida de uma forma geral, no Quality Software KA.
# 4.1 Atributos de Qualidade
* Diversos atributos são geralmente considerados importantes para a obtenção de um design de software de boa qualidade e diversas "ilities" (manutenibilidade, portabilidade, testabilidade, rastreabilidade), várias "des" (correção, robustez), incluindo "fitness de propósito." [Bos00: c5; Bud04: c4; Bus96: c6; ISO9126.1-01; ISO15026-98; Mar94: D; Mey97: c3; Pfl01: c5] Um dado interessante é a distinção entre atributos de qualidade discernable em tempo de execução (desempenho, segurança, disponibilidade, funcionalidade, usabilidade), para aqueles que não discernable em tempo de execução (modificabilidade, portabilidade, reusabilidade, integrabilidade, e testabilidade), e os relacionados com as qualidades intrínsecas da arquitetura (conceitual integridade, a exatidão e a exaustividade, buildability).
# 4.2 Análise de qualidade e Técnicas de Avaliação.
* Várias ferramentas e técnicas podem ajudar a garantir uma concepção da qualidade de software.
o Revisão do design de Software: semi formal ou informal, muitas vezes baseadas em grupo, técnicas para verificar e assegurar a qualidade da concepção de componente (por exemplo, a revisão da arquitetura [Bas03: C11], opiniões de design, e inspeções [Bud04: c4; Fre83: VIII; IEEE1028-97; Jal97: C5, C7; Lis01: C14; Pfl01: c5], técnicas de cenário de base [Bas98: c9; Bos00: c5], rastreio de requisitos [Dor02: v1c4s2; Pfl01: C11]);
o Análise estática: formal ou semi formal estático (não executável) análises que possam ser utilizadas para avaliar um projeto (por exemplo, análise fault-tree ou verificação cruzada automatizada) [Jal97: c5; Pfl01: c5]
o Simulação e prototipagem: técnicas dinâmicas para avaliar um projeto (por exemplo, desempenho ou simulação viabilidade de protótipo [Bas98: c10; Bos00: c5; Bud04: c4; Pfl01: c5])
# 4.3 Medidas
* As medidas podem ser utilizadas para avaliar quantitativamente estimativos ou vários aspectos do tamanho do design de software, estrutura, ou qualidade. A maior parte das medidas que foram propostas dependem geralmente da abordagem utilizada para produzir o design. Estas medidas são classificadas em duas grandes categorias:
* Medidas de Design Orientados a Função (estruturados): a concepção da estrutura, obtido principalmente através da decomposição funcional; geralmente representada como uma estrutura gráfica (às vezes chamado de diagrama hierárquico), em que várias medidas podem ser computadas [Jal97: C5, C7, Pre04 : c15]
* Medidas de Design Orientados a Objeto: a concepção global da estrutura é muitas vezes representada como um diagrama de classes, em que várias medidas podem ser computadas. Medidas sobre as propriedades de cada classe interna do conteúdo também podem ser computadas [Jal97: C6, C7; Pre04: c15]

5 NOTAÇÕES DE DESIGN DE SOFTWARE
* Responsável : igoroliveiracosta@gmail.com

* Muitas notações e linguagens existem para representar o design de software e artefatos. Algumas são usadas principalmente para descrever a organização estrutural de desenho, outras para representar o comportamento de software. Certas notações são usadas pela maior parte durante o desenho arquitetônico e outros principalmente durante detalhamento do desenho, embora algumas notações possam ser usadas em ambos os passos. Além do mais, algumas notações são usadas pela maior parte no contexto de métodos específicos (ver as Estratégias de Desenho de Software e subárea de Métodos). Aqui, eles são categorizados em notações para descrever a visão estrutural (estática) contra a visão comportamental (dinâmica).

5.1. Descrições Estruturais (visão estática)

As seguintes notações, pela maior parte do gráfico (mas não sempre), descrevem e representam os aspectos estruturais de um design de software isto é, eles descrevem os componentes principais e como eles são interligados (visão estática):

* Línguas de descrição de arquitetura (ADLs): textual, muitas vezes formal, línguas usadas para descrever um a arquitetura de software quanto aos componentes e conectores. [Bas03:c12]
* Diagramas de classe e objeto: usado para representar um jogo de classes (e objetos) e as suas relações mútuas. [Boo99:c8, c14; Jal97:c5, c6]
* Diagramas de componentes: usado para representar um jogo de componentes ("parte física e substituível [s] do sistema que [se conformam] com e [fornecem] a realização de um jogo de interfaces" [Boo99]) e suas relações mútuas [Boo99:c12, c31]
* Cartões de colaboração de classes responsáveis (CRCs): usado para denotar os nomes de componentes (classe), suas responsabilidades, e os nomes de seus componentes de colaboração Bus96
* Diagramas de desenvolvimento: usado para representar um jogo de nós (físicos) e as suas relações mútuas, e, assim, modelar os aspectos físicos de um sistema [Boo99:c30]
* Diagramas de entidades e relacionamento (ERDs): usado para representar modelos conceituais de dados fornecidos em sistemas de informação Dor02:v1c5; Mar02:DR
* Línguagens de descrição de interface (IDLs): parecido a com uma linguagem de programação usada para definir as interfaces (nomes e tipos de operações exportadas) de componentes de softwareBoo99:c11
* Estrutura de diagrama Jackson: usado para descrever os dados das estruturas quanto a seqüência, seleção, e iteração Mar02:DR
* Diagramas de estrutura: usado para descrever a estrutura que chama programas (que o módulo chama, e é chamado por outro módulo) Jal97:c5; Mar02:DR;Pre04:c10

5.2. Descrições Comportamentais (visão dinâmica)

As seguintes notações e linguagens, alguns gráficos e alguns textuais, são usados para descrever o comportamento dinâmico de componentes de software. Muitas dessas notações são útil pela maior parte, mas não exclusivamente, durante o detalhamento do design.

* Diagramas de atividade: usado para mostrar o controle de fluxo de atividade ("execução não-atômica contínua dentro de uma máquina de estado") à atividade [Boo99:c19]
* Diagramas de colaboração: usado para mostrar as interações, isto ocorre entre um grupo de objetos, onde a ênfase está nos objetos, as seus links, e as mensagens trocadas entre eles por esses links[Boo99:c18]
* Diagramas de fluxo de dados (DFDs): usado para mostrar fluxo de dados entre um jogo de processos Mar02:DR; Pre04:c8
* Diagramas e tabelas de decisão: usado para representar combinações complexas de condições e ações [Pre04:c11]
* Fluxogramas e fluxogramas estruturados: usado para representar o controle de fluxo e as ações associadas a ser executadas Mar02:DR; Pre04:c11
* Diagramas de seqüência: usado para mostrar as interações entre um grupo de objetos, com ênfase no timeordering de mensagens [Boo99:c18]
* Transição de estado e diagramas de statechart: usado para mostrar o fluxo de controle de estado para estado em uma máquina de estado Bud04:c6; Mar02:DR; Jal97:c7
* Linguagens formais de especificação: linguagens textuais utiliza noções básicas da matemática (por exemplo, a lógica, o jogo, seqüência) para definir com rigor e de maneira abstrata as interfaces de componente de software e comportamento, muitas vezes em termos de pré e pós-condições Dor02:v1c6s5; Mey97:c11
* Pseudocódigo e as linguagens de design de programação(PDLs): as linguagens estruturados-como-linguagens de programação para descrever, geralmente na etapa de detalhamento de design, o comportamento de um procedimento ou método Fre83:VII; Jal97:c7; Pre04:c8, c11

6. ESTRATÉGIAS E MÉTODOS DE DESIGN DE SOFTWARE
* Responsável : igoroliveiracosta@gmail.com
* Existem várias estratégias gerais para ajudar a orientar o processo de planejamento. [Bud04:c9, Mar02:D] Em contraste com as estratégias gerais, os métodos são mais específicos nisto, eles geralmente sugirem e fornecem um conjunto de notações a ser utilizadas com o método, uma descrição do processo a ser utilizado quando o seguinte método e um conjunto de orientações na utilização do método. [Os Bud04:c8] Tais métodos são úteis como um meio de transferir conhecimento e como um framework comum de equipes de engenheiros de software. [Os Bud03:c8] Veja também os Instrumentos de Engenharia de Software e Métodos KA.
6.1 Estratégias Gerais

Algumas vezes, exemplos de estratégias gerais são citados como úteis em design de processo é dividir-e-conquistar em um refinamento gradual Fre83:V, top-down vs. estratégias bottom-up Lis01:c13, abstração de dados e informações ocultas[de Fre83:V], o uso da heurística [Bud04:c8], uso de modelos e linguagens de modelo Bus96:c5, uso de uma aproximação iterativa e incremental. [Pfl01:c2].

6.2 Design orientado por função (Estruturado)

Dor02:v1c6s4; Fre83:V; Jal97:c5; Pre04:c9, c10

Este é um dos métodos clássicos do design de software, onde a decomposição centra na identificação das principais funções de software e refinação elaborando-as de cima para baixo. O design estruturado é geralmente usado depois da análise estruturada, assim produção, entre outras coisas, diagrama de fluxos de dados e descrições de processo associadas. Os pesquisadores propuseram várias estratégias (por exemplo, a análise de transformação, análise de transação) e heurística (por exemplo, fan-in/fan-out, o alcance do efeito contra o alcance do controle) para transformar um DFD em uma arquitetura de software geralmente representada como um diagrama de estrutura.

6.3 Design orientado a objeto

Dor02:v1:c6s2,s3; Fre83:VI; Jal97:c6; Mar02:D; Pre04:c9

Numerosos métodos de design de software baseados em objetos foram propostos. O campo evoluiu com o primeiro design baseado em objeto em meados dos anos 80 (substantivo = objeto; verbo = método; o adjetivo = atributo) pelo design de OO, onde a herança e o polimorfismo desempenham um papel-chave, ao campo do design à base de componente, onde a informação de Meta pode ser definida e acessada (pela reflexão, por exemplo). Embora as raízes de design OO venham do conceito de abstração de dados, o design levado por responsabilidade também tenha sido proposto como uma aproximação alternativa ao design de OO.

6.4 Design centrado por estruturas de dados

Fre83:III,VII; Mar02:D

O desenho centrado por estruturas de dados (por exemplo, Jackson, Warnier-Orr) partidas das estruturas de dados que um programa manipula e não da função que ele executa. O engenheiro de software primeiro descreve os dados de produção e a entrada
das estruturas (usando os diagramas de estrutura de Jackson, por exemplo) e logo desenvolvem a estrutura de controle do programa baseada nesses diagramas de estrutura de dados. Várias heurísticas foram propostas para tratar com casos, por exemplo, especiais, quando há uma má combinação entre as estruturas de produção e entrada.

6.5 Design baseado em componente

Um componente de software é uma unidade independente, tendo interfaces bem definidas e dependências que podem ser compostas e desdobradas independentemente. O design baseado em componente dirige questões relacionadas a fornecimento, desenvolvimento, e integração de tais componentes para melhorar reutilização.[Bud04:c11]

6.6 Outros métodos

Outros interessantes mas com enfoque menor também existem: métodos formais e rigorosos Dor02:c5; Fre83; Mey97:c11; Pre04:c29 e métodos transformacionais. [Pfl98:c2]