Unidade IV

MODELAGEM DE SISTEMAS DE INFORMAÇÃOSISTEMAS DE INFORMAÇÃO

Prof. Daniel Arthur Gennari Junior

Sobre esta aula

Análise Orientada a Objetos

Análise, Definição e Especificação de Requisitos

Modelagem de Casos de Uso

Análise Orientada a Objetos

Inicialmente observamos, como a análise orientada a objeto utiliza conceitos que aprendemos há muito tempo: objetos, atributos, classes, membros, todos e partes.

Só não podemos explicar porque demorou tanto tempo para se aplicarem esses conceitos na análise e especificações dos sistemas de informação.

Análise Orientada a Objetos

Leva em consideração que:

Produto da equipe é um software.

A satisfação dos Propósitos passa por uma interação com os usuários de forma organizada e com isso expõe osorganizada e com isso expõe os requisitos reais do sistema.

Esse software só terá uma qualidade de longa duração se a sua arquitetura aceitar modificações.

Modelagem

É tida como a parte central de todas as atividades para a construção de um bom Sistema. Com ela podemos:

Construir modelos que comunicam a estrutura e o comportamento do sistema;

Construir modelos que visualizam e controlam a arquitetura do Sistema;

Construir modelos que gerenciam os riscos;

Construir modelos que propiciam a Construir modelos que propiciam a simplificação e reaproveitamento de sistemas.

Modelagem Orientada a Objetos

Segundo James Rumbaugh:

“A modelagem baseada em objeto é tida como um novo modo de estudar problemas com a utilização de modelos que são fundamentados em conceitos do mundo real.

A estrutura básica é o objeto, que combina a estrutura e o comportamento dos dados em uma única entidade.

São úteis para a compreensão de p pproblemas, para a comunicação com os peritos em aplicações, para modelar empresas, preparar documentações e projetar programas e bases de dados”.

Principais vantagens da análise OO

Melhor entendimento do problema a ser resolvido;

Maior flexibilidade entre os blocos independentes que são produzidos;

Boa divisão do trabalho entre diferentesBoa divisão do trabalho entre diferentes equipes de desenvolvimento;

Melhor participação dos usuários no processo de desenvolvimento do sistema;

Ajuda a trabalhar com aplicativos Ajuda a trabalhar com aplicativos complexos.

Principais problemas encontrados na análise OO

Exige uma melhor concentração na análise e no projeto do sistema;

Mudança na cultura de desenvolvimento;

Os benefícios são evidenciados a longo prazo.prazo.

Interatividade

A Modelagem de Sistemas é uma atividade que pressupõe a utilização de:

a) Metodologias e procedimentos;

b) Softwares e Frameworks;

c) Bases de comparação;c) Bases de comparação;

d) Bases de interação com o Sistema;

e) N.D.A.

Conceitos de Orientação a Objeto

O it bá i d i t ãOs conceitos básicos de orientação a objeto permitem a definição de:

Classes;

Objetos;

H Herança;

Associações;

Agregação;

Composição;

Encapsulamento;

Métodos;

Polimorfismo;

Interface.

Classe

Segundo Yourdon:

“Classe é uma descrição de um ou mais objetos com conjunto uniforme de atributos e serviços, incluindo uma descrição de como criar novos objetos na classe”.

Classe

A classe é a construção mais importante na orientação a objeto, em que cada classe pode conter: nome, atributo e Método.

Nome: o nome de uma classe é obrigatório e é utilizado para identificá-la diante das outras. Os nomes das classes são substantivos ou expressões breves, definidos a partir do vocabulário do sistema.

Atributo de uma Classe

Atributo: é propriedade nomeado de uma classe que descreve um intervalo de valores cujas instâncias podem apresentar, sendo ele uma abstração do tipo de dado ou do estado que os objetos podem abrangerabranger.

Método de uma Classe

O método é a implementação de um serviço a ser solicitado compartilhado por todos os objetos dentro da classe.

O método pode expressar o comportamento que um objeto apresentar.

Objetos

Um objeto pode ser um lugar, evento, coisa, relatório ou conceito que possa ser aplicado ao sistema, sendo uma abstração, algo que possui um limite nítido e simplificado em relação ao problema.

O objeto facilita a compreensão do mundo real, e oferece a base para a implementação do mundo real no computador.

Herança

A herança mostra a igualdade entre as classes, podendo ser feita a simplificação da definição de classes iguais a outras que já foram definidas. Com isso, é possível representar a generalização e especialização tornando visíveis osespecialização, tornando visíveis os atributos e serviços que são comuns em uma hierarquia de classes. A herança pode ser entendida como um relacionamento entre uma superclasse (classe mãe), e um tipo mais específico chamado de subclassetipo mais específico chamado de subclasse (classe filha). A classe filha herda as características da mãe e pode adicionar novas estruturas ou comportamentos.

Exemplos de herança

Simples: uma classe herda as características apenas de uma classe mãe;

Composta: uma classe herda as características de mais de uma classe mãe.

Associações

As associações são relacionamentos fracos entre os objetos.

Na UML, uma associação pode ser representada como uma linha que liga uma classe a outra.

Agregação

A agregação representa um exemplo de relacionamento do tipo “tem um”, significando que o objeto do todo contém os objetos das partes. Algumas vezes, um objeto é constituído por outros objetos.

Composição

É um caso particular de agregação, utilizado principalmente para evidenciar uma forte conotação de propriedade.

Também especifica que o objeto tem um ciclo de vida, e, quando ele é destruído, as partes também são.

Encapsulamento

Por meio do encapsulamento, podemos ocultar detalhes referentes à implementação do objeto, protegendo os dados contra a adulteração, pois eles só podem ser acessados pelo próprio objeto, pelos seus métodospelos seus métodos.

Métodos

Os métodos são as operações de uma classe. Eles são formados por interfaces que descrevem as características externas do método e pela implementação, que contém o código efetivo para a operação.

Polimorfismo

O polimorfismo permite tratar instâncias de várias classes da mesma forma dentro do sistema.

Ex: O objeto “Francisco” pode ser um estudante, um registro ou mesmo um

Écoordenador. É interessante para os outros objetos saberem que tipo de pessoa Francisco é. O esforço no desenvolvimento seria reduzido se outros tipos de objetos tratassem o objeto pessoa da mesma forma não existindo códigos separadosforma, não existindo códigos separados para cada tipo.

Interface

A interface é um contrato de implementação de métodos de uma classe, que implementa uma interface, e deve implementar todos os métodos que são especificados pela interface.p p

Conclusão

A análise orientada a objeto tem como principal objetivo fazer com que o mundo computacional torne-se o mais próximo possível do mundo real.

Com o auxílio de todos os conceitos que citamos, é possível representar computacionalmente os objetos do mundo real e classificá-los em classes reconhecíveis.

Interatividade

Um dos principais problemas na utilização da Metodologia Orientada a Objetos é:

a) Uso errado dos Métodos;

b) Exige uma melhor concentração na análise e no projeto do sistema;análise e no projeto do sistema;

c) Indisposição da Alta direção;

d) É uma metodologia Nova;

e) N.D.A.

Análise, Definição e Especificação dos Requisitos

A análise de requisitos busca compreender os requisitos solicitados pelo cliente para a construção dos sistemas de informação. É nela que são descritas as abordagens utilizadas para descobrir os requisitos, envolvendo uma equipe técnica que emenvolvendo uma equipe técnica que, em conjunto com os usuários do sistema, estabelece um domínio da aplicação do sistema.

Neste processo de análise, usuários como gerentes engenheiros de manutenção egerentes, engenheiros de manutenção e especialistas de domínio também estão envolvidos, sendo conhecidos como STAKEHOLDERS.

Problemas na análise

O usuário do sistema não possui uma idéia concreta do que deseja, e, mesmo sabendo, existe uma grande dificuldade em se expressar.

O usuário tenta expressar-se utilizando seus próprios termos, supondo que o desenvolvedor sabe o que ele está falando.

Como os requisitos são definidos por diferentes usuários, surgem diversos conflitos, difíceis de serem descobertos, pois os usuários expressam-se de formas diferentes.

Processo de Análise dos Requisitos

Deve ser estabelecida uma compreensão sistemática. O modelo é composto pelas Seguintes atividades:

Compreensão do domínio: é estabelecido um entendimento do domínio da aplicação, em que se deve descobrir o maior número de informações possível.

Coleção de requisitos: é feito um processo de interação com os usuários envolvidos, com a intenção de identificar os requisitos.

Atividades do Modelo

Classificação: classificar a lista de requisitos em categorias coerentes.

Resolução de Conflitos: identificação e resolução de requisitos, decidindo o que fazer quando os requisitos solicitados por um usuário entram em conflito com outros já existentes.

Priorização: definir quais requisitos possuem uma escala maior de prioridade.

Validação: verificar se o conjunto de requisitos é compatível com os solicitados pelos usuários.

Atividades do Modelo

Durante a atividade de análise, três atividades podem ser desenvolvidas:

Particionamento: identifica o relacionamento estrutural entre as atividades.

Abstração: identifica a generalidade entre as atividades.

Projeção: identifica as diferentes formas possíveis de enxergar o mesmo problema.problema.

Requisitos Funcionais

Representam algo que o sistema deve fazer por meio de uma função do sistema que agregue valor ao usuário que o está utilizando.

Ex:Emissão de relatório ou a realização de um cadastro.

Os eventos essenciais têm como função principal a definição de todos os requisitos Funcionais existentes no sistema, respondendo a todos os eventos.

Requisitos não-funcionais

Abordam a forma como os requisitos funcionais podem ser alcançados, definindo restrições e propriedades de um sistema.

Alguns requisitos não-funcionais também são conhecidos como requisitos de qualidade, responsáveis por exigir resistência e robustez do sistema.

EX: a velocidade e a sua transportabilidade.

Outros tipos de Requisitos

Restrições do projeto: limites impostos para que o sistema seja capaz de funcionar no seu ambiente de operação:

Hardware • Software • Rede

Características técnicasCaracterísticas técnicas

Impulsionadores do projeto: forças que fazem o projeto acontecer. Os impulsionadores são geradores de requisitos funcionais e não-funcionais.

Assuntos do projeto: completam o quadroAssuntos do projeto: completam o quadro dos fatores que dizem respeito ao sucesso ou fracasso do sistema.

Verdadeiras ou Falsos

Q d i t d i lQuando um sistema deve cumprir qualquer tecnologia de implementação escolhida, é considerado um requisito verdadeiro, mas quando o sistema cumpre suas finalidades sem que um requisito seja implementado, este é considerado um requisito falsoeste é considerado um requisito falso.

Requisitos tecnológicos falsos:

Tecnologias futuras ou passadas;

Linguagens a serem utilizadas;

Requisitos arbitrários falsos:Requisitos arbitrários falsos:

Influência de ferramentas de modelagem;

Preciosismo;

Ferramentas hipotéticas no sistema.

Requisitos Falsos

A introdução dos requisitos falsos no sistema aumenta os riscos de o projeto não ser completado, pois um requisito falso pode acabar mascarando um requisito verdadeiro.

Para garantir o sucesso de um projeto, devemos buscar apenas os requisitos verdadeiros, mas não é uma tarefa fácil, pois um sistema implementado só com requisitos verdadeiros é considerado um sistema tecnologicamente perfeitosistema tecnologicamente perfeito.

Descrições de Requisitos

Identificador

Tipo

Evento ao qual atende

Descrição

Justificativa

Fonte do requisito

Critérios de aceitação

Satisfação do usuário

I ti f ã d á i Insatisfação do usuário

Dependências

Conflitos

Levantamentos de requisitos

O levantamento dos requisitos aborda as expectativas do sistema, seguindo-se a validação e a consolidação de todas as expectativas em requisitos formais. Essas diferentes visões implicam projetar esses interesses e conciliá losinteresses e conciliá-los.

Busca de fatos

Coletas e Classificação de Requisitos

Racionalização e Avaliação

PriorizaçãoPriorização

Integração e Validação

Ilustrando

Interatividade

Um Sistema de Marketing exigiria os seguintes requisitos:

a) Produtos em Estoque;

b) Vendas de um determinado período;

c) Pontos de vendas de um produto;c) Pontos de vendas de um produto;

d) Fabricação no ano;

e) Todos os requisitos anteriores.

Modelagem de Casos de Uso

Os Modelos mostram como os valores são processados, sem preocupações com:

Ordenamento (sequência) das ações;

As decisões;

As estruturas dos objetos; As estruturas dos objetos;

Dependência de valores entre si e quais as funções que os relacionam.

Modelagem Funcional

Etapas para Modelagem Funcional

Identificar as requisições de entrada e saída;

Construir diagramas mostrando as dependências funcionais;dependências funcionais;

Descrever as funções (casos de uso);

Identificar as restrições.

Diagrama de Casos de Uso

O diagrama de casos de uso exerce um papel importante na análise de Sistemas:

1. É o principal diagrama para ser usado no diálogo com o usuário na descoberta e validação de requisitos;

2. Os casos de uso constituem elementos que estruturam todas as etapas do processo de software.

Analogia com Controle Remoto

Tipos de Interação

Comunicação

Representa quais atores estão ligados a quais casos de uso e é representada pro um arco simples

Usuário

telefone

Tipos de Interação

Inclusão

Um caso inclui outro

Representada através de um arco pontilhado

ExtensãoExtensão

Um caso de uso pode opcionalmente utilizar um outro

DFD e Diagramas de Caso de Uso possuem similaridades

Os DFDs são mais complexos em virtude da maior quantidade de itens

Entidades externas

Depósitos de Dados

Fluxos de DadosFluxos de Dados

Os casos de Uso não descrevem fluxo de Dados

Comentário Final

Os casos de uso são elementos muito importantes na modelagem de um sistema baseado em Processo Unificado.

Todas as atividades de desenvolvimento são organizadas em função dos casos de uso.

Interatividade

Os Casos de Uso são muito importantes para:

a) Promover a interação dos atores com o sistema;

b) Realçar a importância do Sistema;b) Realçar a importância do Sistema;

c) Concluir a modelagem de Dados;

d) Interagir com os usuários;

e) Todos os itens anteriores.

ATÉ A PRÓXIMA!