analise e desenho orientado a objecto · pdf filepassada ao objeto de destino através...

Analise e Desenho

Orientado a Objecto

Msc. Eng. Beldo A. J. Mário

826525385/Bmario@ucm.ac.mz

Eng. de Sw.

• Métodos: proporcionam os detalhes de

"como fazer"para construir o software.

• Ferramentas: fornecem suporte

automatizado ou semi-automatizados aos

métodos.

• Processos: é a fundação da engenharia de

software, provendo a sustentação e

relacionamentos entre as camadas

• Foco na qualidade: garante toda qualidade

do software gerado.

Modelos de Processo

• Uma linguagem de modelagem não é suficiente

precisamos também de um processo de

desenvolvimento

• Linguagem de modelagem + processo de

desenvolvimento = método (ou metodologia) de

desenvolvimento.

Metodologia de Desenvolvimento de

Software

• Especificação de Software

• Projeto e Implementação de Software

• Validação de Software

• Evolução de Software

Metodologias (O Ciclo de Vida do

Desenvolvimento de Sistemas)

Metodologias Ágeis

• Extreme Programming (XP)

• Scrum

• Feature Driven Development ( FDD )

Metodologia de Analise e Desenho

Orientado a Objecto

Análise de Sistemas

Objetivos Básicos:

• Desenvolver a especificação lógica, independente do Software e Hardware utilizado.

• Elaborar um Modelo de Sistema (Ex: Planta de uma Casa)

• Analisar as características importantes ao sistema, tais como, levantamento dos dados, processos e informações que usuário necessita.

• Documentar o processo de análise, para que se tenha uma fidelidade no momento da construção do Software por parte dos projetistas e Desenvolvedores.

Analise Orientado a Objecto

• A AOO é formada por um conjunto de objetos que

interagem entre si, apresentam características

próprias representadas pelos atributos e operações.

• A Análise Tradicional baseia-se na idéia que um

sistema é um conjunto de programas que executam

processos sobre os dados.

Motivos que Levaram ao

surgimento da AOO

• Dificuldade de resolver problemas complexos com

o uso das análises tradicionais

• Surgimento de linguagens de Programação

Orientada a Objetos (C++)

• Necessidade de Desenvolvimento de sistemas

baseado em Real Time com muito mais freqüência

Justificativa de Mudança

• “Objetos já existem na natureza antes de haver

qualquer tipo de aplicação deles pelo negócio:

Equipamentos, pessoas, minerais, etc..., existem

por si só, apresentam características representadas

por seus atributos e, adiante, pelo seu

comportamento no mundo real”.

Problemas da Análise e Projeto

Orientado a objetos

• Fundamentação teórica da AOO não é simples

• Os SGBDs ainda não são totalmente orientado a objetos

• A mudança de mentalidade e introdução de uma nova

tecnologia sempre traz receio

• Existência de várias abordagens para APOO

UML – Unified Modeling Language

ou Linguagem de Modelagem

Unificada

• é uma linguagem visual utilizada para modelar

softwares baseados no paradigma de orientação a

objetos.

• a UML não é uma linguagem de programação, e sim

uma linguagem de modelagem

• podendo ser utilizada por muitos processos de

desenvolvimento diferentes ou mesmo da forma que

o analista considerar mais adequada.

Histórico da UML

• Nos anos 90, conhecida como a época da “guerra

dos métodos”, vários métodos coexistiam com

notações muitas vezes conflitantes entre si. Dentre

estes, os mais conhecidos eram:

• OMT (Object Modelling Technique) de Rumbaugh;

• Método de Booch;

• OOSE (Object Oriented Software Engineering) de

Jacobson;

A importância da Modelagem

• A modelagem consiste em construir um modelo visando

reduzir a incerteza do Software, aproximando-se ao

máximo a expectativa da realização. A modelagem

Orientada a Objetos tem como objetivo:

• Padronizar,

• automatizar,

• incentivar a reutilização de componentes e aumentar a

maturidade em uma equipe de desenvolvimento de um

projeto.

UML – Unified Modeling

Language

Características:• Uma tentativa de padronização das linguagens de modelagem para

ADOO criada a partir da Rational Corporation (http://www.rational.com)e aprovada pela OMG –Object Management Group(http://www.omg.org).

• A UML não é uma metodologia e sim uma linguagem de modelagemque procura integrar as melhores práticas existentes no mercado.

• “É uma linguagem para especificar, visualizar e construir os artefatos desistemas de software...”.

• “É um sistema de notação dirigida à modelagem de sistemas, usandoconceitos orientados a objetos”.

• Tem se tornado um padrão mundial utilizado por desenvolvedores,autores e fornecedores de ferramentas CASE.

• É independente de linguagens de programação OO.

A UML pode ser usada para :

• Mostrar as fronteiras de um sistema e suas funções utilizandoatores e casos de uso

• Ilustrar a realização de casos de usos com diagramas de interação

• Representar uma estrutura estática de um sistema utilizandodiagramas de classe

• Modelar o comportamento de objetos através dos diagramas detransição de estado

• Revelar a arquitetura de implementação física com diagramas decomportamento e de implantação

• Entender sua funcionalidade através de estereótipos.

Conceitos Básicos da Orientada a

Objetos

• Conceitos e Princípios

• Objeto

• Encapsulamento

• Mensagens

• Tipos, Classes

• Herança

Objeto

• um dos principais elementos AOO é o próprio

objeto. Um objeto nada mais é que uma ocorrência

específica de uma classe e é similar a uma entidade

no modelo entidade / relacionamento até no ponto

que uma coleção de dados une-se para formar um

tema em comum.

• Um objeto pode ser: Concreto ou abstrato

Notação de objeto em UML

Classe

• É uma coleção de objetos que podem ser descritos

com os mesmos atributos e as mesmas operações.

Representam uma idéia ou um conceito simples e

categoriza objetos que possuem propriedades

similares. Todos os objetos de uma classe possuem

as mesmas definições, mas podem possuir valores

diferentes nos dados, respondendo de modo

diferente as mensagens enviadas.

A classe Pessoa deverá ter atributos e

métodos comuns

Classe e Objeto

SuperClasse e SubClasse

• Na criação de classe existe a possibilidade de ocorreruma conexão de elementos no modelo Pai / Filho emque uma classe filha ( Subclasse ) herda as propriedadesde seu pai ( superclasse ) direta ou indiretamente.

• Cada classe pode ter suas propriedades particularesherdadas diretamente da classe pai, podendo sersubstituídas ou mascaradas nessa transição. Novaspropriedades poderão ser acrescentadas a classe filha.Todo esse processo narrado acima descreve mais umdos princípios da orientação a objeto:

• Herança.

Herança

• É a capacidade de um novo objeto tomar atributos e

operações de um objeto existente, permitindo criar

classes complexas sem ter que repetir o código.

• Se uma classe herda comportamento e atributos de

mais de uma classe damos a ela o nome de herança

múltipla, uma variação semântica de generalização,

na qual um tipo pode ter mais de um supertipo.

Exemplo:

Mensagens

• Os objetos se comunicam através de mensagens, isto é, um sinalé enviado a um objeto requisitando um serviço, as operações sãoexecutadas e o resultado da operação é enviado ao objetosolicitante.

• Uma mensagem é a chamada de uma função de um objeto, oacionamento de uma operação encapsulada no objeto de destino,feita a partir do objeto de origem. A informação transmitida épassada ao objeto de destino através dos parâmetros de umafunção, enquanto a resposta é passada pelo parâmetro de retornoda função.

• Para que os objetos se comuniquem é necessário que haja algumtipo de ligação / vínculo entre eles. Esses vínculos podem serrelacionamentos entre os objetos.

Polimorfismo

• É a propriedade que o emissor de uma mensagemnão precisa saber a instância da classe que recebeesta mensagem. Essa propriedade leva ao fato deque uma mensagem pode ser interpretada de váriasformas daí o nome Polimorfismo.

• Geralmente as pessoas confundem polimorfismo eencapsulamento porque ambos referem-se aoocultamento da implementação do mundo externoao objeto.

breve descrição dos principais

conceitos da teoria de objetos

Fases do Desenvolvimento de um

Sistema em UML

• Existem cinco fases no desenvolvimento de sistemas desoftware:

• análise de requisitos,

• análise,

• design (projeto),

• programação e

• testes.

• os problemas detectados numa certa fase podem modificar emelhorem as fases desenvolvidas anteriormente de forma queo resultado global gere um produto de alta qualidade eperformance.

Análise de Requisitos

• Esta fase captura as intenções e necessidades dos usuários do sistema aser desenvolvido através do uso de funções chamadas "use-cases".

• Através do desenvolvimento de "use-case“, as entidades externas aosistema que interagem e possuem interesse no sistema são modeladosentre as funções que eles requerem, funções estas chamadas de "use-cases".

• Os atores externos e os "use-cases" são modelados com relacionamentosque possuem comunicação associativa entre eles ou são desmembradosem hierarquia.

• Cada "use-case“ especifica os requerimentos do ator externo queutilizará este "use-case". O diagrama de "use-cases” mostrará o que osatores externos, ou seja, os usuários do futuro sistema deverão esperar doaplicativo, conhecendo toda sua funcionalidade sem importar como estaserá implementada.

Análise

• A fase de análise está preocupada com as primeiras abstrações (classes eobjetos) e mecanismos que estarão presentes no domínio do problema.

• As classes são modeladas e ligadas através de relacionamentos comoutras classes, e são descritas no Diagrama de Classe. As colaboraçõesentre classes também são mostradas neste diagrama para desenvolver os"use-cases" modelados anteriormente, estas colaborações são criadasatravés de modelos dinâmicos em UML.

• Na análise, só serão modeladas classes que pertençam ao domínioprincipal do problema do software, ou seja, classes técnicas quegerenciem banco de dados, interface, comunicação, concorrência eoutros não estarão presentes neste diagrama.

Design (Projeto)

• Na fase de design, o resultado da análise é expandidoem soluções técnicas.

• Novas classes serão adicionadas para prover uma infra-estrutura técnica.

• As classes do domínio do problema modeladas na fasede análise são mescladas nessa nova infra-estruturatécnica tornando possível alterar tanto o domínio doproblema quanto a infra-estrutura.

• O design resulta no detalhamento das especificaçõespara a fase de programação do sistema.

Programação

• Na fase de programação, as classes provenientes do design sãoconvertidas para o código da linguagem orientada a objetos escolhida.

• Dependendo da capacidade da linguagem usada, essa conversão podeser uma tarefa fácil ou muito complicada. No momento da criação demodelos de análise e design em UML, é melhor evitar traduzi-losmentalmente em código.

• Nas fases anteriores, os modelos criados são o significado doentendimento e da estrutura do sistema, então, no momento da geraçãodo código onde o analista conclua antecipadamente sobre modificaçõesem seu conteúdo, seus modelos não estarão mais demonstrando o realperfil do sistema.

• A programação é uma fase separada e distinta onde os modelos criadossão convertidos em código.

Testes

• Um sistema normalmente é rodado em testes de unidade, integração, eaceitação.

• Os testes de unidade são para classes individuais ou grupos de classes esão geralmente testados pelo programador.

• Os testes de integração são aplicados já usando as classes ecomponentes integrados para se confirmar se as classes estão cooperandouma com as outras como especificado nos modelos.

• Os testes de aceitação observam o sistema como uma " caixa preta” everificam se o sistema está funcionando como o especificado nosprimeiros diagramas de "use-cases".

• O sistema será testado pelo usuário final e verificará se os resultadosmostrados estão realmente de acordo com as intenções do usuário final.

EXERCÍCIOS

• 1. Um usuário deseja uma calculadora que efetue as

quatro operações básicas. As expressões permitidas

envolvem apenas dois números, por exemplo, 2 +

3.5ou 3 * 3.2. Identifique os objetos, seus métodos e

atributos.

• 2. Seguindo a abordagem de orientação a objetos, identificar

no enunciado abaixo os objetos e usuários do sistema. Liste os

nomes dos objetos, seus atributos e os usuários do sistema.

• UMA LOCADORA de veículos necessita de um sistema para facilitar o atendimento a

seus clientes. Os carros são classificados por tipo: popular, luxo e utilitário. As

informações que interessam à locadora sobre cada um dos veículos são: placa do carro, tipo e

valor diário do aluguel. Os funcionários da locadora são responsáveis pelo cadastro dos

clientes e dos veículos. Eles também fazem as locações e encerram as mesmas. Há

clientes especiais e comuns. Os especiais têm direito a uma taxa de desconto e um

valor de quilometragem extra nas suas locações. Um cliente é identificado pelo nome,

número do cartão de crédito e data de expiração.

Principais Digramas:

Requisitos

Requisitos.

Identificação e elicitação de

Requisitos:

Documento (Artefato) desta etapa: “Documento de Visão”

As fases da Identificação/Elicitação de

Requisitos:

Identificação dos Requisitos:

Tipos de Requisitos

Os Requisitos de Software podem ser divididos em duas categorias:

Identificação dos Requisitos:

Análise de Requisitos

Atividades da Análise de Requisitos

Análise de Requisitos. Classificar

• Classificacao de Requisitos Não Funcionais:

• Performance: Tempo de resposta

• Segurança: Uso de senhas, certificados digitais e etc..

• Usabilidade: Identidade Visual e Interfaces amigáveis

• Disponibilidade: O software deve estar disponível para usuário 24x7. Exemplo: Tolerância a falha

• Flexibilidade: Capacidade de adaptação quando um requisito muda

• Portabilidade: Capacidade de se adaptar a outros ambientes (sistemas operacionais)

• Escalabilidade: Capacidade de responder aumento de carga (novos usuários)

Especificação de Requisitos

Especificação de Requisitos

Atividades e Passos:

Diagrama de casos de uso

Casos de Uso

Casos de Uso

Casos de Uso e Cenários:

• Os casos de uso exibem a funcionalidade na perspectiva do

usuário. Entretanto, podemos ter vários caminhos para

completar esta função. Um cenários é como uma “instance” do

Caso de uso, isto é, um caminho lógico com início e fim.

Ator

Representação UML (Atores)

Casos de Uso e Fluxo de Eventos:

Tipos de fluxos:

• Fluxo de eventos principal e

• Fluxo alternativo de eventos.

Fluxo de Eventos (1)

Especifica o comportamento de um caso de uso

• E uma sequencia de comandos declarativos que descreve as etapas de execucao de um Caso de Uso

• Permanece focado no domınio do problema e nao em sua solucao

• Pode conter testes condicionais e iteracoes

• Contem informacoes relativas:

• As condicoes de inıcio e termino do caso de uso

• Quais os atores interessados no sistema

• Como o caso de uso interage com esses atores

O fluxo de eventos de um caso de

uso e composto por:

• Um Fluxo Basico - descreve a funcionalidade principal do caso de uso, quando nenhum desvio e tomado

• Zero ou Mais Fluxos Alternativos- descrevem desvios pre-definidos do fluxo basico

• Esses fluxos podem ser especificados atraves de:

• Descricao textual informal

• Texto semi-formal (atraves de pre-pos-condicoes e invariantes)

• Pseudocodigo

• Ou uma combinacao dessas maneiras

Fluxo Basico de Eventos• Descrito em pseudocodigo:

• 1. O cliente chega ao ponto de vendas com os produtos da compra

• 2. para cada( produto trazido pelo cliente):

• (a) O atendente registra o codigo e a quantidade do produto

• (b) O sistema determina o preco do produto e o adiciona `a compra

• 3. O atendente indica que a lista de produtos est´a completa

• 4. O sistema calcula e apresenta o total

• 5. O atendente informa o cliente sobre o total da compra e pergunta qual e a forma de pagamento

• 6. se(dinheiro) forma de pagamento = “dinheiro”

• 7. O atendente registra a quantia recebida

• 8. O sistema mostra o troco e gera o recibo

• 9. O atendente deposita o dinheiro, devolve o troco e entrega o recibo da compra

• 10. O sistema registra o final da transacao

Casos de Uso. Relacionamentos

• Organização dos Casos de Uso:

• Os casos de uso também podem ser organizados pela

especificação de relacionamento de generalização, inclusão

e extensão, existentes entre eles. Esses podem ser

aplicados com a finalidade de fatorar o comportamento

comum (obtendo esse comportamento a partir de outros

casos de uso que ele inclui) e fatorar variantes (obtendo

esse comportamento em outros casos de uso que o

estendem)

Generalização:

• Podemos usar a

generalização entre casos

de uso, pelo mesmo

motivo que utilizamos

nas classes, para

compartilhar

comportamento:

Generalização entre atores

Extends:

Include:

Explicando o estereotipo

“include”

É importante ressaltar que:

• um caso de uso nunca deve ser incluído apenas por um caso, ou seja, não utilizar <<include>> para decompor o diagrama em partes;

• um caso de uso que é incluído por vários outros não tem conhecimento sobre quem o inclui, portanto, podem ser incluídos por qualquer caso sem sofrer modificações;

• não utilizar a relação de inclusão para representar opções de menu, pois o caso que faz a inclusão seria um simples despachante, todo o comportamento estaria fragmentado nos casos incluídos.

• Enfim, inclusão deve ser utilizada para administrar comportamentos comuns e não para estruturar funcionalmente o diagrama.

Associação

Ator x Ator

Ator x Caso

Descricao: Sistema de Ponto de

Vendas

• principais Requisitos:

• Registrar os ´ıtens vendidos em cada venda.

• Calcular o total de uma venda.

• Obter e apresentar as informacoes sobre cada produto mediante a leitura de seu codigo de barras.

• Reportar ao estoque os dados dos produtos vendidos.

• Registrar cada venda completada com sucesso.

• Exigir senha pessoal para operar o sistema.

• Receber pagamentos em dinheiro ou cartao.

• Emitir mensalmente o balanco do estoque.

Exercıcio (PDV)

• Classifica¸c˜ao dos Requisitos - (F/NF):

• • Registrar os ´ıtens vendidos em cada venda.

• • Calcular o total de uma venda.

• • Obter e apresentar as informa¸c˜oes sobre cada produto mediante a leitura de seu c´odigo de barras.

• • Reportar ao estoque os produtos vendidos.

• • Registrar cada venda completada com sucesso.

• • Exigir senha pessoal para operar o sistema.

• • Receber pagamentos em dinheiro ou cart˜ao.

• • Emitir mensalmente o balan¸co do estoque.

Exemplo (Caso de Uso)

• Caso De Uso: Comprar Produtos

• Atores: Cliente, Atendente

• Descricao: Um cliente chega ao ponto de vendas para

comprar produtos. O atendente registra a compra e

coleta o pagamento. O cliente vai embora com a

compra.

Exemplo (Fluxo Basico de Eventos)

• Descrito em pseudocodigo:

• 1. O cliente chega ao ponto de vendas com os produtos da compra

• 2. para cada ( produto trazido pelo cliente):

• (a) O atendente registra o codigo e a quantidade do produto

• (b) O sistema determina o preco do produto e o adiciona `a compra

• 3. O atendente indica que a lista de produtos esta completa

• 4. O sistema calcula e apresenta o total

• ...

...

• 5. O atendente informa o cliente sobre o total da compra e pergunta qual e a forma de pagamento

• 6. se (dinheiro) forma de pagamento = “dinheiro”

• 7. O atendente registra a quantia recebida

• 8. O sistema mostra o troco e gera o recibo

• 9. O atendente deposita o dinheiro, devolve o troco e entrega o recibo da compra

• 10. O sistema registra o final da transacao