You are here: Wiki-SL>OOPTQ Web>WebHome (27 Nov 2012, TonyGuards?)EditAttach

GRUPO DE ESTUDOS DE ORIENTAÇÃO A OBJETOS

ETE TAQUARITINGA

Introdução

Mancing | Kue Kering Segundo Fernandes sistema é um conjunto de elementos interrelacionados que interagem no desempenho de uma função. Dessa forma, podemos dizer que um sistema computacional é a relação entre a máquina(hardware), o programa(software) e as pessoas(peopleware), e tem por objetivo resolver problemas do dia a dia.

Para Anquetil o desenvolvimento de um pequeno programa é fácil, mas em um grande sistema há dificuldades como:

  • Desenvolvidos por muitas pessoas
  • Pessoas que saem e entram no projeto
  • Má definição do escopo do sistema
  • Difícil entendimento do usuário leigo com a linguagem técnica
  • Dificulade de estimar prazos e recursos

Então para minimizar as falhas e atrasos no desenvolvimento do software, existem ferramentas e procedimentos que facilitam a documentação e possibilitam a melhoria da definição do escopo do software que será desenvolvido.

Fases do Desenvolvimento do Software
Para que um software atinja as necessidades do usuário, existem algumas fases a serem seguidas.

  • Fase de levantamento de dados
  • Fase de análise e projeto
  • Fase de implementação
  • Fase de testes e validações
  • Fase de disponibilização do software(implantação)

Vamos nos ater as fases de levantamento de dados e de análise e projeto, que possui um ciclo de vida próprio. Existem várias metodologias utilizadas pelo mercado como a Análise Estruturada, Análise Essencial e Análise Orientada a Objetos. Utilizaremos como base a Análise Orientada a Objetos com foco na UML. Podemos dizer que a metodologia de desenvolvimento de sistemas é um roteiro de trabalho sobre o qual é visualizado todas as etapas de construção de um software, suas interdependências, bem como o progresso do mesmo.

Análise Orientada a Objeto

A análise orientada a objeto, assim como outras metodologias de programação, tem como função representar problemas do domínio do mundo real e encontrar soluções através da simulação em programas. As diferenças com as metodologias estruturais basicamente estão em três conceitos de programação: abstração, ocultamento de informações e modularidade, todas obtidas sem complexidade e compromisso através da programação orientada a objeto.

As linguagens de modelagem orientadas a objetos surgiram entre a metade da década de 1970 e o final da década de 1980, à medida que o pessoal envolvido com metodologia, diante de um novo gênero de linguagens de programação orientadas a objeto e de aplicações cada vez mais complexas, começou a experimentar métodos alternativos de análise e projeto. A quantidade de métodos orientados a objetos aumentou de pouco mais de 10 para mais de 50 durante o período de 1989 a 1994. Muitos usuários desses métodos tiveram dificuldades para encontrar uma linguagem de modelagem capaz de atender inteiramente às suas necessidades.

Conceitos Básicos

Classe: A modelagem de um conceito do mundo real. As propriedades associadas ao conceito são representadas por atributos (variáveis) e operações (i.e. funções). Uma classe descreve os atributos que seus objetos vão ter e as funções que podem executar.

Objeto: A modelagem de um objeto do mundo real. Cada objeto do mundo real pode ser representado por um objeto. Cada objeto "pertence'' a uma classe. A estrutura do objeto como as operações que ele pode executar são descritas pela classe. Objetos são entidades independentes uns dos outros. Dois objetos com exatamente os mesmos atributos são dois objetos diferentes. Na informática, se pode pensar na memória de um computador: dois objetos com os mesmos atributos, estão em diferentes partes da memória, na verdade eles tem um atributo implícito (o endereço na memória onde eles ficam) que é diferente.

Instância: É o ato de transformar uma classe em um objeto.

Propriedade: Um conceito é definido por um conjunto de propriedades. Por exemplo, uma pedra tem as seguintes propriedades: dura, inanimada, sólida, e muito mais. Uma classe modela um conceito listando algumas das suas propriedades interessantes, considerando o problema a resolver. Por exemplo, a data de nascimento de um aluno vai ser uma propriedade interessante. A cor dos cabelos é também uma propriedade do conceito aluno, mas provavelmente, não é importante no modelo e não será modelada.

Método: Uma propriedade importante de uma classe que pode ser representada com uma função. Por exemplo, a idade de um aluno pode ser calculada a partir da data de nascimento e da data do dia corrente.

Herança: A modelagem da noção de especialização/generalização. No mundo real, conceitos são especializações uns dos outros: um professor visitante é um caso especial de professor; um professor, um aluno são seres humanos; um ser humano é um animal, ...Os conceitos mais especiais têm todas as propriedades dos conceitos mais gerais, mais algumas propriedades em si próprio. No modelo a objetos, uma sub-classe possui todos os atributos e todas as operações da super-classe. A sub-classe pode acrescentar alguns atributos e métodos. Ela pode também redefinir alguns métodos da super-classe (dentro de alguns limites que estudaremos). Ela não pode tirar nenhuma propriedade da super-classe.

Polimorfismo: Várias classes podem implementar a mesma operação de maneira diferente. A mesma operação (com o mesmo nome) tem várias ("poli") formas ("morfismo") em cada classe. Uma característica poderosa do modelo a objetos é que todas as formas de uma operação podem ter o mesmo nome. Assim se torna mais fácil de reconhecer qual operação um método particular implementa. Isso é possível porque cada objeto sabe qual é sua própria classe, e pode executar os métodos apropriados.

Linguagem de Modelagem Unificada (UML)

UML significa Unified Modeling Language (linguagem de modelagem unificada). Ela deriva principalmente da unificação das linguagens de modelização de três métodos: o "OMT'' de Rumbauch, o "método de Booch'' e os "casos de uso'' de Jacobson. Cada um foi bem sucedido como método de análise orientada a objeto, e o objetivo da UML é tirar vantagem das principais caraterísticas de cada um deles. O Projeto da UML procurou desenvolver uma linguagem de modelagem que atingisse as seguintes metas:
  • Prover à comunidade uma linguagem de modelagem visual pronta para o uso e expressiva, possibilitando desenvolver e intercambiar modelos significativos.
  • Fornecer extensibilidade e mecanismos de especialização para estender os conceitos centrais.
  • Suportar especificações que são indeoendentes de processos de desenvolvimento e linguagens de programação particlares.
  • Prover uma base formal para o entendimento da linguagem de modelagem.
  • Encorajar o crescimento do mercado de ferramentas de objetos.
  • Integrar melhores práticas.

História
Para entender porque a UML se tornou um padrão mundial é interessante conhecermos como ela nasceu e como se desenvolveu até chegar a sua versão atual (versão 2.0).

No início dos conceitos de O.O. (Orientação a Objetos), diversos métodos apresentados para a comunidade. Chegaram a mais de 50 entre os anos de 1989 a 1994, porém a maioria deles cometeu o erro de tentar estender os métodos estruturados da época. Com isso os maiores prejudicados foram os usuários, no caso nós, que não conseguiam encontrar uma maneira satisfatória de modelar seus sistemas. Essa situação ficou conhecida como a guerra dos métodos.

Foi a partir da década de 90 que começaram a surgir teorias que procuravam trabalhar de forma mais ativa com o paradigma da orientação a objetos. Diversos autores famosos contribuíram com publicações de seus respectivos métodos. Por volta de 1993 existiam 3 métodos que mais cresciam no mercado, eram eles Booch3 de Grady Booch, OMT-2 de James Rumbaugh e OOSE de Ivar Jacobson. Cada um deles possuía pontos fortes em alguma parte. O OOSE possuía foco em casos de uso (use cases), OMT-2 se destaca na faze de analise de sistemas de informação e Booch’93 era mais forte na fase de projeto. O sucesso desses métodos se deu principalmente ao fato de não terem tentado estender os métodos já existentes. Seus métodos já convergiam de maneira independente, então seria mais produtivo continuar de forma conjunta.

Em outubro de 1994 começaram os esforços para unificação dos métodos. Já em outubro de 1995 Booch e Rumbaugh lançaram um rascunho do Método Unificado unificando o Booch’93 e o OMT-2, após isso Jacobson se juntou a equipe do projeto e o Método Unificado passou a incorporar o OOSE. os E foi em junho de 1996 os três amigos, como já eram conhecidos, lançaram a primeira versão com os três métodos, a versão 0.9 que foi batizada como UML. Daí em diante várias novas versões na qual podemos acompanhar através do gráfico abaixo: imagem.JPG

A OMG3 lançou uma RFP (Request for Proposals) para que outras empresas pudessem contribuir com a evolução da UML, daí se chegou a versão 1.1. Após alcançar esta versão, a OMG3 passou a adotá-la como padrão e a se responsabilizar (através da RTF Revision Task Force) pelas revisões. Essas revisões são controladas a não provocar uma grande mudança no escopo original. E realmente foi isso que aconteceu, se observarmos as diferenças entre as versões, veremos que de uma para a outra não houve grande impacto, o que facilitou sua disseminação pelo mundo.

Desenvolvimento de um Sistema em UML
A UML suporta as todas as fases de desenvolvimento de Software. As fases não necessariamente devem ser executadas em uma ordem seqüencial. Para a documentação necessária das fases, a UML na versão 2 disponibiliza 13 diagramas, que são uma representação gráfica parcial ou total de um modelo.

Diagramas
Diagrama de pacotes: É usado para dividir o modelo em containers lógicos ou em "pacotes" e descreve as interações entre eles em alto nível.

Diagrama de classes: Define os elementos básicos de um modelo: os tipos, as classes e os relacionamentos são que são usados para construir um modelo completo.

Diagrama de objetos: Similar ao diagrama de classes porém sua principal diferença é que ele apresenta os atributos com valores. Corresponde a uma instância do diagrama de classes, mostrando o estado de um sistema em um determinado ponto do tempo.

Diagrama de estrutura composta: Fornece meios de definir a estrutura de um elemento e de focalizá-la no detalhe, na construção e em relacionamentos internos

Diagrama de componentes: Apresenta as dependências entre componentes de softwares, incluindo implementação de classes, arquivos de código fonte, arquivo de código binário, arquivos executáveis e scripts.

Diagrama de instalação: Mostra a configuração dos elementos de processamento em tempo de execução, além dos componentes, processos e objetos do sistema neles existentes.

Dinâmicos ou de Comportamento: Os diagramas dinâmicos ou de comportamento apresentam as variedades da interação e do estado instantâneo dentro de um modelo enquanto é executado.

Diagrama casos de uso: É usado para modelar interações do usuário/sistema. Definem o comportamento, as exigências e o resultado esperado de uma funcionalidade.

Diagrama de máquina de estados: Representa as ações ocorridas em reposta a ao recebimento de um evento, onde cada ponto de parada representa um estado da aplicação.

Diagrama de atividades: É uma variação do diagrama de máquina de estados. Representa a execução das ações e as transições que são acionadas pela conclusão de outras ações ou atividades.

Diagrama de comunicação: Exibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles.

Diagrama de seqüência: É usado para representar o comportamento das operações, métodos (procedimentos ou funções) entre classes de um cenário.

Diagrama de Tempo: É a fusão do diagrama de seqüência e estado apresentando o comportamento dos objetos e sua interação em uma escala de tempo, ou seja, o estado dos objetos em relação ao tempo e as mensagens que modificam esse estado.

Diagrama de Interatividade: É a fusão do diagrama de atividades e seqüência. Ele permite que fragmentos das interações sejam facilmente combinados aos pontos e fluxos de decisão.

Técnicas de Levantamento de dados
Através das técnicas de levantamento de dados, será definido o escopo do projeto a ser desenvolvido, abaixo seguem algumas técnicas que podem ser utilizadas nesse trabalho:

Entrevista

Observação Pessoal

Análise de Documentos

Questionário

Brainstorm

A definição do escopo é de vital importância para o bom andamento do projeto, pois através dele é que será desenvolvido o sistema. As técnicas serão utilizadas durante toda a fase do projeto, mas é essencial que no inicio, tente se levantar a maior quantidade possível de informação, pois se houver uma definição errada nesse momento, pode compromenter todo o projeto, implicando em retrabalho, atrasos ou até mesmo o cancelamento do projeto.

analista.JPG

Para facilitar o andamento, utilizaremos a idéia do dividir para conquistar, onde definiremos os módulos funcionais do sistema(ou cenários), facilitando dessa forma o bom entendimento.

Por módulos funcionais podemos definir por exemplo módulo de compras, módulo de vendas, agendamento de consulta, atendimento, etc. Para cada módulo anexaremos a documentação utilizada pelas técnicas, como questionários ou documentos e por fim faremos umas descrição textual, definindo dessa forma o que deverá ser feito no módulo.

Utilizaremos então, o diagrama de caso de uso, para definir o comportamento do módulo.

Diagramas de Caso de Uso
A modelagem de um diagrama use-case é uma técnica usada para descrever e definir os requisitos funcionais de um sistema. Eles são escritos em termos de atores externos, use-cases e o sistema modelado. Os atores representam o papel de uma entidade externa ao sistema como um usuário, um hardware, ou outro sistema que interage com o sistema modelado. Os atores iniciam a comunicação com o sistema através dos use-cases, onde o use-case representa uma sequência de ações executadas pelo sistema e recebe do ator que lhe utiliza dados tangíveis de um tipo ou formato já conhecido, e o valor de resposta da execução de um use-case (conteúdo) também já é de um tipo conhecido, tudo isso é definido juntamente com o use-case através de texto de documentação.

Atores e use-cases podem ser classes. Um ator é conectado a um ou mais use-cases através de associações, e tanto atores quanto use-cases podem possuir relacionamentos de generalização que definem um comportamento comum de herança em superclasses especializadas em subclasses.

O uso de use-cases em colaborações é muito importante, onde estas são a descrição de um contexto mostrando classes/objetos, seus relacionamentos e sua interação exemplificando como as classes/objetos interagem para executar uma atividade específica no sistema. Uma colaboração é descrita por diagramas de atividades e um diagrama de colaboração.

Quando um use-case é implementado, a responsabilidade de cada passo da execução deve ser associada às classes que participam da colaboração, tipicamente especificando as operações necessárias dentro destas classes juntamente com a definição de como elas irão interagir. Um cenário é uma instância de um use-case, ou de uma colaboração, mostrando o caminho específico de cada ação. Por isso, o cenário é um importante exemplo de um use-case ou de uma colaboração. Quando visto a nível de um use-case, apenas a interação entre o ator externo e o use-case é vista, mas já observando a nível de uma colaboração, toda as interações e passos da execução que implementam o sistema serão descritos e especificados.

Os casos de uso tem por objetivo:

  • Descrever um conjunto de atividades de um sistema sob o ponto de vista de seus atores.
  • Decidir e descrever os requisitos funcionais do sistema.
  • Fornecer uma descrição clara e consistente do que o sistema deve fazer.
  • Delimitar o contexto de um sistema.
  • Permitir descobrir os requisitos funcionais das classes e operações do sistema.

Podemos dizer que os componentes de um modelo de casos de uso são :

Ator: é um papel que tipicamente estimula/solicita ações/eventos do sistema e recebe reações. Cada ator pode participar de vários casos de uso.

Ator.jpeg

Casos de uso: documento narrativo que descreve a sequencia de eventos feitos por um ator no uso do sistema.

Caso.jpeg

Relacionamentos entre Casos de Uso

Caso de Uso (estende ou extend)
Estende - descreve comportamento opcional ou excepcional de um caso de uso, executado sob certas condições.
Ex: Nota Fiscal

Caso de Uso (inclui, include, use ou usa)
- Inclui - indica uma funcionalidade compartilhada por vários casos de uso.
Ex: Baixar Estoque

Definição do Caso de Uso

Nome do caso de uso: Nome do caso de uso (um parágrafo).

Atores: Lista dos nomes dos atores com descrição curta.

Descrição Qual a função do caso de uso

Pre-Condições: Lista de condições que têm que ser verificadas antes que o caso de uso começa.

Pós-Condições: Lista de condições que têm que ser verificadas depois do fim do caso de uso.

A descrição do caso de uso pode conter condições que tem que ser verificadas (verdadeiras) antes o caso ser executado (pré-condições) ou depois que for executado (pós-condições).

As pré-condições especificam qual é o estado do sistema antes do caso começar. As pós-condições indicam em qual estado o caso de uso vai deixar o sistema. Essas condições tem que ser verdadeiras independentemente do cenário que for executado (incluindo um possível cancelamaneto).

Fluxo de eventos

Fluxo principal
1. Primeiro passo no caso de uso.
2. Segundo passo no caso de uso.
3. ...

Fluxos alternativos
Descrever os fluxos alternativos.

Um caso de uso descreve um fluxo de eventos. Normalmente, para cumprir uma operação, pode ter vários fluxos de eventos alternativos.

Cada fluxo de eventos, cada caminho de interação desde o início da tarefa até o fim é chamado de cenário.

A maioria das operações são amplas demais para nós descrevermos todos os cenários simultaneamente. Para simplificar o trabalho, vamos procurar definir independentemente cada cenário. Isto deve também nos ajudar achar todos os cenário possíveis.

Vamos sempre definir primeiro o ``fluxo principal'' de eventos que é o cenário ``normal'', sem erros, nem cancelamento, etc.

Em geral, esse caso será aquele que um usuário vai descrever em primeiro lugar também. É o caso básico a partir do qual poderemos acrescentar variações, nuançes e casos "anormais'' (erros, cancelamentos, etc.)

Dicas
Procurar primeiro os atores que interagem com o sistema. Para isso, procurar responder perguntas como: Quem usa o sistema? Quem o instala? Quem o inicia ou o pára? Quem faz a manutenção? Quem entra dados no sistema? E quem precisa/usa dados do sistema?

É bom definir um pequeno dicionário dos atores, que descreve sucintamente cada ator. Isso permite verificar que temos uma idéia clara de o que o ator representa e permite também verificar com os usúarios as definições dos atores.

Depois, para cada ator, procurem definir quais operações ele precisa fazer. Uma interação é uma troca de dados: Quem fornece dados para quem (o sistema para o ator ou o ator para o sistema ou os dois)? Quem cria, consulta, modifica ou destrói os dados?

Sempre definir em primeiro o fluxo de eventos principal de um caso de uso sem se preocupar com os fluxos alternativos.

Diagramas de Classe
Após a criação dos diagramas de caso de uso, faremos os diagramas de classe, definindo dessa forma as classes que serão utilizadas no projeto.

Uma classe é a descrição de um tipo de objeto. Todos os objetos são instâncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto. Objetos só podem ser instanciados de classes. Usam-se classes para classificar os objetos que identificamos no mundo real. Tomando como exemplo Charles Darwin, que usou classes para classificar os animais conhecidos, e combinou suas classes por herança para descrever a "Teoria da Evolução". A técnica de herança entre classes é também usada em orientação a objetos.

O diagrama de classes demonstra a estrutura estática das classes de um sistema onde estas representam as "coisas" que são gerenciadas pela aplicação modelada. Classes podem se relacionar com outras através de diversas maneiras: associação (conectadas entre si), dependência (uma classe depende ou usa outra classe), especialização (uma classe é uma especialização de outra classe), ou em pacotes (classes agrupadas por características similares). Todos estes relacionamentos são mostrados no diagrama de classes juntamente com as suas estruturas internas, que são os atributos e operações. O diagrama de classes é considerado estático já que a estrutura descrita é sempre válida em qualquer ponto do ciclo de vida do sistema. Um sistema normalmente possui alguns diagramas de classes, já que não são todas as classes que estão inseridas em um único diagrama e uma certa classes pode participar de vários diagramas de classes.

Em UML as classes são representadas por um retângulo dividido em três compartimentos:

Nome: Que conterá apenas o nome da classe modelada. Todas as classes devem ter um nome que as diferencie das demais. Usamos uma seqüência de caracteres para identificá-las. Uma classe pode ter um nome simples, ou com caminho. O caminho identifica o pacote ao qual a classe pertence.

Atributos: Que possuirá a relação de atributos que a classe possui em sua estrutura interna. Um atributo é uma propriedade de uma classe, que descreve um intervalo de valores que as instâncias da propriedade podem apresentar. Uma classe pode ter qualquer número de atributos ou nenhum. Um atributo representa o tipo de dados ou estados que cada item de uma classe pode assumir, são representados logo após o nome da classe.

Operações: Que serão os métodos de manipulação de dados e de comunicação de uma classe com outras do sistema. As Operações são os processos que a classe pode realizar. As Operações correspondem claramente a métodos em uma classe. No nível de especificação, as operações correspondem a métodos públicos. Normalmente, você não mostra as operações que simplesmente manipulam atributos, porque elas podem ser freqüentemente inferidas. Entretanto, você poderá ter que identificar seu um dado atributo é somente para leitura (isto é, o seu valor nunca muda). No modelo de implementação, você também pode querer mostrar operações privativas (private) e protegidas (protected). Uma classe pode ter várias operações ou até mesmo nenhuma, são representadas logo após os atributos.

Classe.jpeg

Relacionamentos entre classes

Os objetos tem relações entre eles: um professor ministra uma disciplina para alunos numa sala, um cliente faz uma reserva de alguns lugares para uma data, etc. Essas relações são representadas também no diagrama de classe.

Geralmente as classes não estão sós e se relacionam entre si. O relacionamento e a comunicação entre as classes definem responsabilidades. A UML reconhece três tipos mais importantes de relações: generalização (ou herança), associação e dependência.

Generalização

Herança é um dos conceitos fundamentais da programação Orientada à Objeto, na qual uma classe “herda” todos os atributos e operações da classe da qual deriva, e pode sobrescrever/modificar alguns deles, bem como adicionar mais atributos e operações próprios.

EM UML, uma associação Generalização entre duas classes coloca-as numa hierarquia representando o conceito de herança de uma classe derivada de uma classe base. Em UML, Generalizações são representadas por uma linha conectando duas classes, com uma seta no lado da classe base.

Heranca.jpeg

Associações

Um associação representa um relacionamento entre classes, e fornece a semântica comum e a estrutura para muitos tipos de conexões entre objetos.

Associações são o mecanismo que permite objetos comunicarem-se entre si. Elas descrevem a conexão entre diferentes classes (a conexão entre os objetos atuais é chamada conexão do objeto, ou link.

Associações podem ter um regra que especifica o propósito da associação e pode ser uni ou bidirecional (indicadando se os dois objetos participantes do relacionamento podem mandar mensagens para o outro, ou se apenas um deles sabe sobre o outro). Cada ponta da associação também possui uma valor de multiplicidade, que dita como muitos objetos neste lado da associação pode relacionar-se com o outro lado.

Em UML, associações são representadas como linhas conectando as classes participantes do relacionamento, e podem também mostrar a regra e a multiplicidade de cada um dos participantes. A multiplicidade é exibida como um intervalo [min..máx] de valores não negativos, com uma estrela (*) no lado máximo representando infinito.

Associacao.jpeg

  • Composição: Composições são associações que representam agregações muito fortes. Isto significa que Composições formam relacionamentos todo-parte também, mas o relacionamento é tão forte que as partes não pode existir independentes. Elas existem somente dentro do todo, e se o todo é destruído as partes morrem também. Em UML, Composições são representadas por um rombóide sólido no lado do todo.

Composicao.jpeg

  • Agregação: Agregações são um tipo especial de associação no qual as duas classes participantes não possuem em nível igual, mas fazem um relacionamento todo-parte. Uma Agregação descreve como a classe que possui a regra do todo, é composta (tem) de outras classes, que possuem a regra das partes. Para Agregações, a classe que age como o todo sempre tem uma multiplicidade de um. Em UML, Agregações são representadas por uma associação que mostra um rombóide no lado do todo.

Agregacao.jpeg

Dependência

A dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe.

Topic attachments
I Attachment Action Size Date Who Comment
docdoc Apostila_UML.doc manage 373.5 K 11 Jan 2007 - 11:56 NelsonSadala Apostila de UML
Topic revision: r29 - 27 Nov 2012 - 07:55:35 - TonyGuards?
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Wiki-SL? Send feedback