Análise e design orientado a objetos - Object-oriented analysis and design

Análise e design orientado a objetos ( OOAD ) é uma abordagem técnica para analisar e projetar um aplicativo, sistema ou negócio aplicando programação orientada a objetos , bem como usando modelagem visual em todo o processo de desenvolvimento de software para orientar a comunicação das partes interessadas e a qualidade do produto.

O OOAD na moderna engenharia de software é normalmente conduzido de forma iterativa e incremental. Os resultados das atividades OOAD são modelos de análise (para OOA) e modelos de design (para OOD), respectivamente. A intenção é que sejam continuamente refinados e evoluídos, impulsionados por fatores-chave como riscos e valor para o negócio.

História

Nos primórdios da tecnologia orientada a objetos, antes de meados da década de 1990, havia muitas metodologias diferentes para desenvolvimento de software e modelagem orientada a objetos , muitas vezes vinculadas a fornecedores de ferramentas de Engenharia de Software Auxiliada por Computador (CASE). Nenhuma notação padrão, termos consistentes e guias de processo eram as principais preocupações na época, o que degradou a eficiência da comunicação e alongou as curvas de aprendizado.

Algumas das primeiras metodologias orientadas a objetos bem conhecidas foram inspiradas em gurus como Grady Booch , James Rumbaugh , Ivar Jacobson (os Três Amigos ), Robert Martin , Peter Coad , Sally Shlaer , Stephen Mellor e Rebecca Wirfs-Brock .

Em 1994, os Três Amigos da Rational Software começaram a trabalhar juntos para desenvolver a Unified Modeling Language (UML). Mais tarde, junto com Philippe Kruchten e Walker Royce (filho mais velho de Winston Royce ), eles lideraram uma missão de sucesso para fundir suas próprias metodologias, OMT , OOSE e método Booch , com vários insights e experiências de outros líderes da indústria no Rational Unified Process (RUP), um guia de processo iterativo e incremental abrangente e estrutura para aprender as melhores práticas da indústria de desenvolvimento de software e gerenciamento de projetos. Desde então, a família Unified Process tornou-se provavelmente a metodologia e modelo de referência mais popular para análise e design orientado a objetos.

Visão geral

O ciclo de vida do software é normalmente dividido em estágios, indo de descrições abstratas do problema para projetos, em seguida, para código e teste e, finalmente, implantação. Os primeiros estágios desse processo são análise e design. A fase de análise também é freqüentemente chamada de "aquisição de requisitos".

O modelo em cascata .

OOAD é conduzido de maneira iterativa e incremental, conforme formulado pelo Processo Unificado .

Em algumas abordagens de desenvolvimento de software - conhecidas coletivamente como modelos em cascata - os limites entre cada estágio devem ser bastante rígidos e sequenciais. O termo "cascata" foi cunhado para tais metodologias para significar que o progresso foi sequencialmente em apenas uma direção, ou seja, uma vez que a análise foi concluída, então e somente então o design foi iniciado e era raro (e considerado uma fonte de erro) quando um problema de design exigia uma mudança no modelo de análise ou quando um problema de codificação exigia uma mudança no design.

A alternativa aos modelos em cascata são os modelos iterativos. Essa distinção foi popularizada por Barry Boehm em um artigo muito influente sobre seu Modelo Espiral para desenvolvimento de software iterativo. Com modelos iterativos é possível trabalhar em várias etapas do modelo em paralelo. Portanto, por exemplo, é possível - e não visto como uma fonte de erro - trabalhar em análise, design e até mesmo código, tudo no mesmo dia e ter problemas de um estágio impactando os problemas de outro. A ênfase em modelos iterativos é que o desenvolvimento de software é um processo intensivo de conhecimento e que coisas como a análise não podem ser totalmente compreendidas sem a compreensão dos problemas de design, que os problemas de codificação podem afetar o design, que o teste pode gerar informações sobre como o código ou mesmo o design deve ser modificado, etc.

Embora seja possível fazer o desenvolvimento orientado a objetos usando um modelo em cascata, na prática a maioria dos sistemas orientados a objetos são desenvolvidos com uma abordagem iterativa. Como resultado, em processos orientados a objetos, "análise e design" são frequentemente considerados ao mesmo tempo.

O paradigma orientado a objetos enfatiza a modularidade e a reutilização. O objetivo de uma abordagem orientada a objetos é satisfazer o "princípio aberto-fechado" . Um módulo é aberto se ele suporta extensão, ou se o módulo fornece maneiras padronizadas de adicionar novos comportamentos ou descrever novos estados. No paradigma orientado a objetos, isso geralmente é realizado criando uma nova subclasse de uma classe existente. Um módulo é fechado se tiver uma interface estável bem definida que todos os outros módulos devem usar e que limita a interação e os erros potenciais que podem ser introduzidos em um módulo por alterações em outro. No paradigma orientado a objetos, isso é realizado definindo métodos que invocam serviços em objetos. Os métodos podem ser públicos ou privados, ou seja, certos comportamentos exclusivos do objeto não são expostos a outros objetos. Isso reduz a fonte de muitos erros comuns na programação de computadores.

O ciclo de vida do software é normalmente dividido em estágios, indo de descrições abstratas do problema para projetos, em seguida, para código e teste e, finalmente, implantação. Os primeiros estágios desse processo são análise e design. A distinção entre análise e design é freqüentemente descrita como "o quê vs. como". Na análise, os desenvolvedores trabalham com usuários e especialistas de domínio para definir o que o sistema deve fazer. Os detalhes de implementação devem ser ignorados na maior parte ou totalmente (dependendo do método específico) nesta fase. O objetivo da fase de análise é criar um modelo funcional do sistema, independentemente das restrições, como a tecnologia apropriada. Na análise orientada a objetos, isso normalmente é feito por meio de casos de uso e definições abstratas dos objetos mais importantes. A fase de design subsequente refina o modelo de análise e faz a tecnologia necessária e outras opções de implementação. No design orientado a objetos, a ênfase está em descrever os vários objetos, seus dados, comportamento e interações. O modelo de design deve ter todos os detalhes necessários para que os programadores possam implementar o design no código.

Análise orientada a objetos

O objetivo de qualquer atividade de análise no ciclo de vida do software é criar um modelo dos requisitos funcionais do sistema que seja independente das restrições de implementação.

A principal diferença entre a análise orientada a objetos e outras formas de análise é que, pela abordagem orientada a objetos, organizamos os requisitos em torno dos objetos, que integram comportamentos (processos) e estados (dados) modelados a partir de objetos do mundo real com os quais o sistema interage. Em outras metodologias de análise ou nas tradicionais, os dois aspectos: processos e dados são considerados separadamente. Por exemplo, os dados podem ser modelados por diagramas ER e comportamentos por fluxogramas ou gráficos de estrutura .

Os modelos comuns usados ​​em OOA são casos de uso e modelos de objeto . Os casos de uso descrevem cenários para funções de domínio padrão que o sistema deve realizar. Os modelos de objeto descrevem os nomes, relações de classe (por exemplo, Círculo é uma subclasse de Forma), operações e propriedades dos objetos principais. Maquetes ou protótipos da interface do usuário também podem ser criados para ajudar na compreensão.

Design orientado a objetos

Durante o projeto orientado a objetos (OOD), um desenvolvedor aplica restrições de implementação ao modelo conceitual produzido na análise orientada a objetos. Essas restrições podem incluir as plataformas de hardware e software , os requisitos de desempenho, armazenamento e transação persistentes, usabilidade do sistema e limitações impostas por orçamentos e tempo. Os conceitos do modelo de análise que é independente da tecnologia são mapeados em classes e interfaces de implementação, resultando em um modelo do domínio da solução, ou seja, uma descrição detalhada de como o sistema deve ser construído em tecnologias concretas.

Tópicos importantes durante o OOD também incluem o design de arquiteturas de software aplicando padrões de arquitetura e padrões de design com princípios de design orientado a objetos.

Modelagem orientada a objetos

A modelagem orientada a objetos (OOM) é uma abordagem comum para modelar aplicativos, sistemas e domínios de negócios usando o paradigma orientado a objetos em todos os ciclos de vida de desenvolvimento . OOM é uma técnica principal amplamente utilizada pelas atividades OOD e OOA na moderna engenharia de software.

A modelagem orientada a objetos normalmente se divide em dois aspectos do trabalho: a modelagem de comportamentos dinâmicos, como processos de negócios e casos de uso , e a modelagem de estruturas estáticas, como classes e componentes. OOA e OOD são os dois níveis abstratos distintos (ou seja, o nível de análise e o nível de design) durante o OOM. A Unified Modeling Language (UML) e SysML são as duas linguagens padrão internacionais populares usadas para modelagem orientada a objetos.

Os benefícios do OOM são:

Comunicação eficiente e eficaz

Os usuários geralmente têm dificuldades em compreender bem documentos abrangentes e códigos de linguagem de programação. Os diagramas de modelo visual podem ser mais compreensíveis e permitir que os usuários e partes interessadas forneçam feedback aos desenvolvedores sobre os requisitos e a estrutura apropriados do sistema. Um objetivo principal da abordagem orientada a objetos é diminuir a "lacuna semântica" entre o sistema e o mundo real, e fazer com que o sistema seja construído usando uma terminologia que seja quase a mesma que as partes interessadas usam nos negócios diários. A modelagem orientada a objetos é uma ferramenta essencial para facilitar isso.

Abstração útil e estável

A modelagem ajuda a codificação. Um objetivo da maioria das metodologias de software modernas é primeiro abordar as questões "o quê" e depois as questões "como", ou seja, primeiro determinar a funcionalidade que o sistema deve fornecer sem levar em consideração as restrições de implementação e, em seguida, considerar como fazer soluções específicas para essas questões requisitos e refiná-los em projetos e códigos detalhados por restrições como tecnologia e orçamento. A modelagem orientada a objetos permite isso ao produzir descrições abstratas e acessíveis dos requisitos e designs do sistema, ou seja, modelos que definem suas estruturas e comportamentos essenciais como processos e objetos, que são ativos de desenvolvimento importantes e valiosos com níveis de abstração mais altos acima do código-fonte concreto e complexo .

Veja também

Referências

Leitura adicional

• Grady Booch . "Análise e design orientado a objetos com aplicativos, 3ª edição": http://www.informit.com/store/product.aspx?isbn=020189551X Addison-Wesley 2007.
• Rebecca Wirfs-Brock , Brian Wilkerson, Lauren Wiener. Projetando Software Orientado a Objetos . Prentice Hall, 1990. [ Uma introdução prática à programação e design orientado a objetos. ]
• Uma Teoria do Projeto Orientado a Objetos : Os blocos de construção do OOD e as notações para representá-los (com foco nos padrões de projeto).
• Martin Fowler . Padrões de análise: modelos de objetos reutilizáveis . Addison-Wesley, 1997. [ Uma introdução à análise orientada a objetos com modelos conceituais ]
• Bertrand Meyer . Construção de software orientado a objetos . Prentice Hall, 1997
• Craig Larman . Aplicando UML e Padrões - Introdução ao Desenvolvimento OOA / D & Iterative . Prentice Hall PTR, 3ª ed. 2005., mnnm, n, nnn
• Setrag Khoshafian. Orientação a objetos .
• Ulrich Norbisrath, Albert Zündorf, Ruben Jubeh. Modelagem baseada em histórias . Amazon Createspace. p. 333., 2013. ISBN   9781483949253 .

links externos

• Artigo Análise e design orientado a objetos com UML e RUP uma visão geral (também sobre cartões CRC).
• Aplicação de UML - tutorial de Análise e Design Orientado a Objetos
• Site e fóruns de recursos OOAD e UML - Análise e design orientado a objetos com UML .
• Artigo de Análise de Requisitos de Software usando UML por Dhiraj Shetty.
• Artigo Análise Orientada a Objetos no Mundo Real