1 - lafayette b. melo – análise e projeto de sistemas para a internet – coinfo – cefet-pb 8....

11 - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB - Lafayette B. Melo – Análise e Projeto de Sistemas para a Internet – COINFO – CEFET-PB

8. Análise e projeto orientados a objetos e UML 8. Análise e projeto orientados a objetos e UML (casos de uso)(casos de uso)

8.1 A junção da análise orientada a objetos com a UML e com 8.1 A junção da análise orientada a objetos com a UML e com outros métodosoutros métodos8.2 Casos de uso8.2 Casos de uso

Objetivo: compreender os acréscimos dados a análise Objetivo: compreender os acréscimos dados a análise orientada a objetos e aplicar casos de usoorientada a objetos e aplicar casos de uso

em UMLem UML


• 8.1 A junção da análise orientada a objetos com a 8.1 A junção da análise orientada a objetos com a UML e com outros métodosUML e com outros métodos

• UML (unified modeling language) é uma linguagem para especificar, visualizar e construir os artefatos de sistemas de software

• É um padrão aceito para a indústria para a modelagem orientada a objetos

• Resultou de um esforço conjunto de três autores e da aceitação da OMG (object management group) – Grady Booch– Jim Rumbaugh– Ivar Jacobson– http://www.omg.org

• UML tem ao menos dez/treze notações/diagramas e é voltada para modelar e não para dizer como fazer uma análise ou projeto


UML 1.XUML 1.X UML 2.0UML 2.0

Atividade Atividade

Caso de uso Caso de uso

Classe Classe

Objetos Objetos

Sequência Sequência

Colaboração Comunicação

Estado Estado

Pacotes

Componentes Componentes

Instalação Implantação

Interação – Visão geral

Timing

Composite structure diagram

Atualizações em UML estão em http://www.omg.org/tecnology/documents/formal/uml


• É importante compreender que a UML surgiu como uma linguagem que integrava a modelagem orientada a objetos com outras notações– UML também não é orientação a objetos em si

• Razões do que é hoje UML– I) Padronização e mudanças de metodologias e notações– II) Resposta aos velhos problemas do software

• I) Padronização e mudanças de metodologias e I) Padronização e mudanças de metodologias e notaçõesnotações

– De uma maneira geral, transposição do modelo em cascata para um processo unificado


– De uma maneira mais específica, um conjunto de fatos históricos que resultaram na união dos “três amigos”


• PERGUNTA CRUCIAL:

• Como estabeleceremos nossa metodologia de desenvolvimento?– RUP?– XP?– ICONIX?– AM?– Remendos de outras metodologias, hibridismos, ecletismos?

– E as questões para a Web?– E as questões de hoje sobre software livre?– Há questões específicas, por exemplo, para o desenvolvimento

de produtos educacionais?

– Etc, etc e etc


• Além da padronização e mudanças de metodologias e notações dos “três amigos” atender um apelo comercial, há razões para esta padronização que dizem respeito II)II) aos velhos problemas do softwareaos velhos problemas do software……

– 1) O software não apresenta a mesma constância que em outras áreas

– 2) A “burrice” do usuário X a “burrice” de não entender que os requisitos de software sofrem mudanças


• Na concepção do software – o usuário pode ter certa uma necessidade, mas a forma de resolver ou atender a necessidade não tem um formato definido

– Na área civil, o engenheiro pode delimitar a medida e as Na área civil, o engenheiro pode delimitar a medida e as possibilidades de terreno em um formato definidopossibilidades de terreno em um formato definido

• Na aprovação da concepção – o usuário requer conhecimento específico sobre as modelagens e outras questões que lhe formos remeter, mesmo se for da área de informática, para amadurecer sua idéia inicial

– Na área civil, ele vê a planta sabendo o que é uma Na área civil, ele vê a planta sabendo o que é uma paredeparede

• No detalhamento das necessidades – após às funcionalidades escritas a própria equipe de desenvolvimento descobre suas inconsistências

– Na área civil, isso simplesmente não aconteceNa área civil, isso simplesmente não acontece


• No início da construção – a idéia de como atender a necessidade muda a partir de um formato

– Na área civil, geralmente os requisitos simplesmente não Na área civil, geralmente os requisitos simplesmente não mudam (já imaginou quebrar as paredes de um quarto mudam (já imaginou quebrar as paredes de um quarto porque se viu que uma cama de casal não cabia?)porque se viu que uma cama de casal não cabia?)

• Nos testes – problemas podem ocorrer pelo fato de o usuário não participar e até haver a demissão anterior de um elemento da equipe

– Na área civil, o usuário normalmente visita a obra Na área civil, o usuário normalmente visita a obra periodicamente e a demisão de um trabalhador não periodicamente e a demisão de um trabalhador não afeta que outro continue o mesmo trabalhoafeta que outro continue o mesmo trabalho

• Na entrega – normalmente, o usário diz “não era bem isso que eu queria” ou pede mais uma modificação

– O que representaria tal frase depois de uma casa O que representaria tal frase depois de uma casa entregue?entregue?


– 3) Não há uma forma CORRETA de construir software, pois esta construção depende de vários fatores atuando em conjunto:

• Conhecimento do negócio a ser modelado• Conhecimento da tecnologia a ser utilizada• Capacidade de abstração do usuário• Capacidade de abstração do desenvolvedor• Dinheiro e outros recursos…

– 4) Relações MODELAGEM X REALIDADE

– 5) Intangibilidade

– 6) Condições de automatizar algo que já tem em pleno vigor (problema para os casos de uso, ver adiante!)

– 7) Má formação profissional em informática (ver o profissional dos casos de uso – o analista de negócios – adiante!)


• … Poratno, mudanças devem existir, são bem-vindas e a MODELAGEM DE SOFTWARE deve considerar isso principalmente ao se utilizar os casos de uso (adiante) !!!!!


• 8.2 Casos de uso8.2 Casos de uso

• O caso de uso é a mais importante construção de orientação a objetos, utilizando UML– Acompanha do início ao fim da conclusão– Acontece em todas as iterações

• Conceitos importantes:– Ator

• É uma pessoa, um sistema, uma entidade externa, um roteador

• Representa um determinado papel


– Caso de uso• Macroatividade que encerra diversas tarefas ou atividades• Ex.: Pagamento de compras

» Atividades – mostrar e validar cartão, informar valor debitado, informar senha que permite o débito, validar senha, retorno da instituição financeira, resumo da operação

• Ex.: imprimir nota fiscal• O limite de um caso de uso é uma decisão pessoal


• Quanto um caso de uso deve ser descrito?– Com bastantes detalhes– Com objetividade que não sacrifique a composição do detalhe– Aplicado a partir de abstrações

• Quem faz a extração dos casos de uso?– Um profisional habilitado em análise de negócios– Métodos usados

• Observação• Entrevista

– Perfil do profissional de casos de uso:• Boa capacidade de comunicação interpessoal

– # de extrovertidp# de extrovertidp– Com capacidade de ouvir # escutarCom capacidade de ouvir # escutar

• Capacidade de escrever o que ouviu• Bom relacionamento interpessoal• Cultura geral


• Como extrair casos de uso?– Sugestão de estrutura de caso de uso

Nome referência: AB200501 – Nome do caso de usoVerbo no infinitivo (informar, comprar, pagar)

Breve descritivoInformar o que trata o caso de uso

Pré-condiçõesDescrição que informa o que é necessário para que este caso de uso se inicie

Atores envolvidos

Cenário principalDescrição do mundo perfeito, sem exceções (presente do indicativo e substantivos)

Cenário alternativo

Requisitos especiais

Dados

Observação

Analista de negócio:___________________________________

Entrevistado:________________________________________

Área:_______________________________________________

Data:___/___/___

Versão:


• Como lidar com as mudanças de requisito nos casos de uso?

– Entender que requisito é uma condição ou capacidade que um software deve ter

– Entender que mudança de requisito não é mudança do negócio• Essas implicam não só novos modelos, mas novos

documentos, novos prazos e novos preços• Dependerá de uma avaliação coletiva e da comunicação

entre os stakeholders

• Quem e como é aprovado um caso de uso?– Em primeiro lugar, seu colega– Por qualquer meio– Nunca, caso de uso um a um


• Modelar “o que é” ou “como será”?– Se o negócio existir e se desejar levar ele para a Internet,

retratar “como é”– Se o usuário disser que gostaria de modelar “diferente”,

modele “como será”– Enfim, pense como um analista de objetos

• Como acompanhar o progresso dos casos de uso?– Reuniões quinzenais ou mensais

• O que usar, além da forma escrita?– Gráficos, organogramas e uma notação padrão adiante


• Notação gráfica para casos de uso


• Exemplos


9. Modelo conceitual (diagrama conceitual de 9. Modelo conceitual (diagrama conceitual de classes)classes)

9.1 Conceitos9.1 Conceitos9.2 Associações9.2 Associações9.3 Atributos9.3 Atributos

Objetivo: compreender e aplicar um modelo Objetivo: compreender e aplicar um modelo conceitual conceitual

Aluno Professor

ensina*1..*


• Um modelo conceitual mostra os conceitos significativos PARA QUEM MODELA o sistema no domínio de uma determinada atividade

• É necessário que sejam identificados conceitos adequados a partir da investigação de um problema para que o projeto e a implementação sejam feitos também de forma mais adequada

• Uma série de esforços (dicas) devem ser despendidos pelo MODELADOR para a construção do modelo conceitual

• DICA 1: deve-se ter um esforço para pensar no modelo conceitual como uma representação de coisas do mundo real e nunca como componentes de software


• DICA 2: o modelo conceitual é sempre feito a partir dos casos de uso

• O modelo conceitual trata de conceitos, associações entre conceitos e atributos de conceitos

• Exemplo dos pontos de venda que pode partir de diversos pontos de vista de caso de uso


Página 102


• 9.1 Conceitos9.1 Conceitos

• Conceitos são idéias, coisas ou objetos– Mais especificamente

• Símbolos – palavras ou imagens representam conceitos• Intenções – definições de conceitos• Extensões – conjunto de exemplos aos quais o conceito se

aplica

• Por exemplo, “colocar material na página” é um evento cujo símbolo eu posso escolher “material”?

• DICA 3: a análise deve sempre ser orientada a objetos. Cuidado para não dividir por funções!!


Página 104


• DICA 4: Estratégias para se identificar conceitos a partir de um caso de uso– Principal: especificar muitos conceitos (SEM PENA!!!!!)– Enfoque 1 – Criar um modelo conceitual a partir de uma lista de

categorias de conceitos

Categoria de conceitoCategoria de conceito ExemplosExemplos

Objetos físicos ou tangíveis POST

Especificação de projeto ou descrição de objeto EspecificaçãodeProduto

Lugares Loja

Transações Venda, Pagamento

Linhas de itens de transações LinhadeItemdeVenda

Papéis Caixa

Contêineres Depósito, armário

Objetos dos contêineres Item

Outros sistemas SistemadeCartãodeCrédito


Categoria de conceitoCategoria de conceito ExemplosExemplos

Substantivos abstratos Fome

Organizações DepartamentodeVendas

Eventos Venda, Roubo, Reunião

Processo VendendoumProduto

Regras e estratégias PolíticadeReembolsos

Catálogos CatálogodeProdutos

Registros Recibo, DiáriodeCaixa

Serviços LinhadeCrédito

Manuais, livros ManualdoEmpregado

– Enfoque 2 – Criar um modelo conceitual a partir da identificação de substantivos

• CUIDADO: não trabalhar mecanicamente!


• Exemplo na sequência de eventos do caso de uso Comprar Itens

Açao do AtorAçao do Ator Resposta do SistemaResposta do Sistema

1. Este caso de uso começa quando um Cliente chega a um ponto de pagamento com POST, com vários itens que deseja comprar

2. O caixa registra o Código Universal de Produto (UPC) de cada item

3. Determina o preço do item e acrescenta informação sobre o item à transação de vendas em andamento

Se houver mais de um exemplar do item, o Caixa também pode entrar a quantidade

A descrição e o preço do item corrente são apresentados


• DICA 5: objetos-relatórios, incluir ou não?– No caso do ponto de venda

• I) recibo é relatório de venda e mostrar relatório em um modelo conceitual não é útil porque toda a informação é derivada de outras fontes

• II) recibo tem um papel importante: dá direito ao portador de retornar itens comprados pelo mesmo

• De uma maneira geral, deve-se usar a “regra do cartógrafo”!


• ERROS COMUNS:

– 1) representar algo como atributo quando deve ser um conceito

• Dica: se você pensa em um conceito X como um número ou um texto no mundo real, provavelmente é um conceito e não um atributo

– 2) ignorar conceitos de especificação• Dica: no mundo real, uma especificação é algo que não é

necessariamente intrinseco a um objeto, já que, se assim fosse, se os objetos acabassem, as epecificações acabariam também


• 9.2 Associações9.2 Associações

• Associações são relacionamentos entre conceitos com algum significado para o domínio de conhecimento

• Exemplo do ponto-de-venda

Página 118


• DICA 6: as associaçõe devem ser encontradas a partir de uma lista de categorias de associações comuns

Categoria Categoria ExemploExemplo

A é uma parte física de B Gaveta-POST

A é uma parte lógica de B LinhadeItemVenda-Venda

A está fisicamente em / sobre B POST-Loja

A está logicamente em / sobre B Descriçãodeitem-Catálogo

A é descrição de B DescriçãodeItem-Catálogo

A é linha de item de transação/relatório B LinhadeItemVenda-Venda

A é conhecido/logado/registrado por B Venda-POST

A é membro de B Caixa-Loja

A usa/gerencia B Caixa-POST

A é subunidade de B Departamento-Loja

A se comunica com B Cliente-Caixa

A relacionado com transação B Cliente-Pagamento

A é transação relacionada com transação B Pagamento-Venda

A é vizinho/de lado de B POST-POST

A é possuído por B POST-Loja


• DICA 7: nunca se dedicar mais a associações do que a conceitos

• DICA 8: focalizar as associações que são necessárias de ser conhecidas

• DICA 9: evitar associações redundantes e deriváveis

• Papéis: cada extremo de uma associação com:– Nome– Multiplicidade– Navegabilidade


Página 120 e 121


Página 122


• Exemplo do modelo conceitual para ponto de vendas

Página 125


• 9.3 Atributos9.3 Atributos

• Valores de dados lógicos de um objeto

• DICA 10: colocar atributos para os quais os requisitos indicam que as informações devem ser memorizadas

• Exemplo para ponto de venda

Página 129


• DICA 11: como diferenciar atributos de associações– Deixar os atributos simples

Página 130


– Identificados como aqueles para os quais uma entidade única não faz sentido

– Em nehuma hipótese definir atributo como chave estrangeira

• DICA 12: pensar o modelo conceitual principalmente como uma ferramenta de comunicação


• Exemplo completo para o ponto de vendas

Página 138

1 - lafayette b. melo – análise e projeto de sistemas para a internet – coinfo – cefet-pb 8....

Documents