Olá pessoal, esse é meu primeiro artigo aqui no site da DevMedia na seção MSDN, como dito no meu artigo de apresentação irei abordar desde a análise ao desenvolvimento de um sistema de software. Nesse meu primeiro artigo irei apresentar uma introdução à Análise Orientada a Objetos, ou se preferirem OOA.

Nos últimos anos, o mercado começou a absorver cada vez mais o desenvolvimento de sistemas de softwares Orientados a Objetos, mas a Orientação a Objetos não é muito nova, não irei entrar em detalhes de quando ela começou a ser estudada/desenvolvida, nem por quem, já que foge do objetivo desse artigo.

No contexto do desenvolvimento de sistemas de softwares orientados a objetos, podemos compreender a OOA como o processo para diminuir a distância conceitual entre o mundo real (domínio do problema), identificando e definindo um conjunto de objetos que interagem e comportam-se conforme os requisitos do sistema.

Utilizamos a UML (Unified Modeling Languagem) para especificar, visualizar, documentar e construir artefatos de um sistema de software. A UML foi homologada em 1997 pela OMG (Object Management Group). Podemos dividir o processo de OOA em 4 grupos: Use Case View, Logical View, Component View e Deployment View.

  • Use Case View: É a visão de análise e modelagem de um sistema de software.
  • Logical View: É a visão do projeto.
  • Component View: É a visão dos componentes físicos do projeto.
  • Deployment View: É a visão de implantação.

Para representarmos os objetos, ações, estados, nesses quatro grupos utilizamos 9 diagramas: Diagrama de Caso de Uso, Diagrama de Classes, Diagrama de Objetos, Diagrama de componentes, Diagrama de implantação, Diagrama de Atividade, Diagrama de Estado, Diagrama de Colaboração, Diagrama de Seqüência.

A primeira coisa a ser feita na OOA é o Modelo Descritivo, que conterá informações sobre o problema a ser solucionado, o objetivo do projeto, os requisitos funcionais e não funcionais, as atividades do sistema e soluções de automação.

  • Objetivo do Projeto: Visa especificar todas as funcionalidades que serão automatizadas pelo sistema com base nas informações do problema a ser solucionado.
  • Requisitos Funcionais: Mostram as funcionalidades do sistema que será desenvolvido.
  • Requisitos não funcionais: Qualificam os requisitos funcionais.
  • Atividades do Sistema: Define o fluxo das ações do sistema.
  • Soluções de automação: Especificar equipamentos e softwares necessários para o funcionamento do sistema.

Conclusões

Hoje nós tivemos uma visão geral da OOA, a forma de faze - lá e os itens necessários para um documento de OOA. Nos próximos artigos iremos abordar com mais detalhes cada item necessários para OOA.