Análise (I)

Prof. Giovani Motter

[email protected]

Análise e Projeto de Sistemas Orientado a Objetos Análise e Projeto de Sistemas Orientado a Objetos

utilizando UMLutilizando UML

FACULDADE IGUAÇU – CapanemaFACULDADE IGUAÇU – Capanema

Especialização em Java com desenvolvimento para webEspecialização em Java com desenvolvimento para web

Análise e Projeto de Sistemas Orientado a Objetos utilizando UML – Prof. Giovani MotterAnálise e Projeto de Sistemas Orientado a Objetos utilizando UML – Prof. Giovani Motter 2

Análise (I)

A análise enfatiza a investigação do problema; O objetivo da análise é levar o analista a

investigar e a descobrir; Para que esta etapa seja realizada em menos

tempo e de forma mais precisa, deve-se ter um bom método de trabalho;

Pode-se dizer que o resultado da análise é o enunciado do problema, e que o projeto será a sua solução;

Problemas mal enunciados podem até ser resolvidos, mas a solução não corresponderá às expectativas.


Análise (II)

A qualidade do processo de análise é importante porque:

Um erro de concepção resolvido na fase de análise tem um custo;

Um erro na fase de projeto tem um cuto maior; Um erro na fase de implementação tem um custo

maior ainda; Um erro na fase de implantação tem um custo

astronômico, ou mesmo pode representar o fracasso do projeto.


Projeto

A fase de projeto enfatiza a proposta de uma solução que atenda os requisitos da análise.

Então, se a análise é uma investigação para tentar descobrir o que o cliente quer, o projeto consiste em propor uma solução com base no conhecimento adquirido na análise.


Implementação

A utilização de técnicas sistemáticas nas fases de análise e projeto faz com que o processo de geração de código possa ser automatizado;

Neste caso, cabe ao programador dominar a características específicas da linguagens, ferramentas, frameworks e estruturas de dados para adaptar o código gerado aos requisitos indicados quando necessário.


Testes

A fase de testes envolve:

os testes de unidade (unit tests), feitos pelo programador, para verificar se os componentes gerados atendem à especificação do projetista;

os testes de caso de uso, normalmente efetuados por um analista experiente, que visam identificar a adequação do sistema aos requisitos inicialmente levantados;


Quatro fases do RUP (Rational Unified Process)

A fase de concepção incorpora o estudo de viabilidade e uma parte da análise de requisitos;

A fase de elaboração incorpora a maior parte da análise de requisitos, a análise de domínio e o projeto;

A fase de construção corresponde à programação e testes;

A fase de transição consiste na instalação e manutenção do sistema;


RUP (Rational Unified Process)


Análise de Requisitos (I)

A análise de requisitos é fundamental para o desenvolvimento de sistemas, pois trata justamente de descobrir o que o cliente quer com o sistema;

A análise de requisitos está associada ao processo de descobrir quais são as operações que o sistema deve realizar e quais são as restrições que existem sobre estas operações;


Análise de Requisitos (II)

Requisitos podem ser: Funcionais: o que o sistema deve fazer; Não-Funcionais: restrições sobre como o sistema

deve desempenhar suas funções. “De que forma, como, quando, onde, para quem, por quanto tempo, etc. Tais operações se realizam?” são perguntas típicas.

Exemplo: Registrar o empréstimo de um filme é um requisito

funcional; Estabelecer que o tempo de empréstimo da fita não

pode ser superior a 48 horas é uma restrição, ou requisito não-funcional.


Análise de Domínio

A análise de domínio está relacionada à descoberta das informações que são gerenciadas no sistema, ou seja, à representação e transformação da informação.

Exemplo: No sistema de informações de uma vídeo-locadora, as

informações descobertas na análise de domínio possivelmente seriam relativas aos clientes, às fitas, aos empréstimos, aos pagamentos, etc.

Deve ficar claro ao analista que requisitos são as “coisas” que o cliente ou usuário solicitam, e não “coisas” que ele, como analista, planejou.


Concepção / Iniciação (I)

Levantamento de Requisitos Entrevistas Análise de Documentos Estudo Bibliográfico Comparativo

Organização de Requisitos Planejamento dos Ciclos Iterativos

Objetivos da Concepção / Iniciação: Buscar as primeiras informações sobre o sistema a

ser desenvolvido; Descobrir se vale a pena fazer a análise, mas sem

fazer a análise propriamente dita;


Concepção / Iniciação (II)

Atividades da fase de Concepção / Iniciação: Descobrir / Modelar a visão da empresa para o

sistema;• O que a empresa quer com o projeto?• Por que ele está sendo proposto?• Há tempo disponível? Construir ou Comprar?• O cliente tem dinheiro para pagar o desenvolvimento?• O projeto é viável / realizável?

Levantar requisitos; Organizar requisitos; Planejar o desenvolvimento:

• Métricas;• Cronograma;• Recursos.


Características do RUP

Iterativo e Incremental

Orientado a Casos de Uso

Centrado em Arquitetura


Modelagem de Sistemas Orientados a Objetos

Antigamente não havia uma forma padrão de se analisar e modelar sistemas orientados a objetos.

Diferentes metodologias levavam a um desentendimento e confusão por parte de analistas e desenvolvedores, por suas diferentes características, elementos conceituais e notação.

Algumas metodologias eram boas em determinadas características, mas ruins ou inexistentes em outras necessidades da análise e modelagem OO.

Grady Booch, James Rumbaugh e Ivar Jacobson (“os três amigos”) se juntaram, unificaram suas metodologias e criaram a UML, pegando o melhor de cada e melhorando com o suporte e ajuda da comunidade.


Unified Modeling Language (UML)

UML é uma linguagem de modelagem de sistemas, usada para: Especificar; Modelar; Visualizar; Documentar.



A UML é dividida em algumas partes, como segue: Visões: Mostram os diferentes aspectos do sistema,

dando enfoque a ângulos e níveis de abstrações diferentes, construindo uma visão completa do sistema a ser construído.

Modelos de Elementos: São os conceitos utilizados nos diagramas. Representam definições comuns da OO.

Mecanismos Gerais: Provém comentários suplementares, informações ou semântica sobre os elementos dos modelos.

Diagramas: São gráficos que descrevem o conteúdo em uma visão. A UML possui vários tipos de diagramas que, combinados, formam todas as visões do sistema.



Por que usar UML? Desenvolver o modelo de uma aplicação antes de

construí-la, é tão essencial quanto ter uma planta para a construção de uma casa.

Bons modelos são essenciais para a comunicação entre os times de projetos e para assegurar a beleza arquitetural.

Com o aumento da complexidade dos sistemas, é importância conhecer boas técnicas de modelagem.

Ter um rigoroso padrão de linguagem de modelagem é um fator essencial para o sucesso de um projeto.

Como a UML se tornou uma notação padrão da indústria de arquitetura de software, ela é assunto abordado em muitos livros, seminários e sites.


Modelos de Elementos da UML

Os elementos da UML são blocos de construção para os modelos dos diagramas e são essenciais para o entendimento da UML.

Cada elemento tem um propósito diferente, diferentes regras e notações;

Alguns elementos podem ser usados em diferentes diagramas;

Existem um grande conjunto de elementos disponíveis na especificação;

Vamos estudar os principais elementos especificados pela UML.



Caso de Uso É a descrição de um conjunto de seqüências de

ações realizadas pelo sistema, que proporciona resultados observáveis de valor para um determinado ator.

Ator O Ator é alguém ou algo externo ao sistema, mas

que vai interagir com o sistema.



Classe É a descrição de conjunto de objetos que

compartilham os mesmos atributos (estado) e operações (comportamento).

Objeto Um objeto é uma instância de uma classe, em

tempo de execução.



Pacote É um mecanismo de propósito geral para a

organização de elementos em grupo.

Nota A nota é apenas um símbolo para representar

restrições e comentários anexados a um elemento. Geralmente usa-se a nota para aprimorar os diagramas.


Modelos de Elementos da UML - Relacionamentos

Os elementos dos modelos UML estão ligados uns aos outros, especificando o que cada elemento significa ao outro e qual o grau de ligação deles, ou seja, qual a relação lógica entre os elementos.

Existem diferentes tipos e graus de relacionamentos. São eles: Associação Generalização Dependência Refinamento



Associação A associação representa uma ligação entre dois

elementos. As associações ainda podem expressar a

cardinalidade e a navegação (sentido) da associação.

A cardinalidade (ou multiplicidade) indica quantos elementos são possíveis de cada lado da associação e pode ser expressada como um número ou um intervalo.



Agregação Este é um caso particular de associação. Indica que um elemento é parte ou está contida em

outra classe. Representa uma relação do tipo parte/todo.



Composição ou Agregação de Composição É uma relacionamento onde um elemento está

contido em outro, ou seja a vida de um depende do outro, e o seus tempos de vida são os mesmos.



Generalizações A generalização é um relacionamento entre um

elemento mais geral e um mais específico. O elementos mais específico possui todas as

características do seu elemento mais geral, como as propriedades e seu comportamento, além de poder adicionar mais características a ele mesmo.



Dependência A dependência é uma conexão semântica entre

dois elementos, um independente e outro dependente.

Qualquer alteração no elemento independente pode afetar o elemento dependente.

Em classes, a dependência indica que o elemento apenas instancia e/ou usa o elemento independente, sem manter uma relação duradoura com o elemento.

Análise e Projeto de Sistemas Orientado a Objetos utilizando UML – Prof. Giovani MotterAnálise e Projeto de Sistemas Orientado a Objetos utilizando UML – Prof. Giovani Motter

Diagramas UML

Principais diagramas UML para projetos Orientado a Objetos: Diagrama de Casos de Uso Diagrama de Atividades Diagrama de Classes Diagrama de Objetos Diagrama de Estados Diagrama de Seqüência Diagrama de Colaboração Diagrama de Componentes Diagrama de Execução


Diagrama de Caso de Uso (I)

O Diagrama de Casos de Uso serve para: Visualizar os relacionamentos entre os atores e os

casos de uso do sistema (cenários), numa visão geral.

Levantar os requisitos funcionais do sistema.


Diagrama de Caso de Uso (II)


Diagrama de Caso de Uso (III)


Diagrama de Atividades (I)

O Diagrama de Atividades mostra o fluxo de controle.

Tipicamente as atividades são estados de ação – estados que transitam para outro estado, assim que a ação tenha sido completada.

Este diagrama pode ser usado em qualquer nível: fluxo dos casos de uso, fluxo no nível de programação, fluxo das regras de negócio, etc.


Diagrama de Atividades (II)


Diagrama de Classes (I)

Mostra a estrutura estática do modelo da aplicação;

Exibe as classes do sistema e o grau do relacionamentos entre elas.


Diagrama de Classes (II)


Diagrama de Objetos

O Diagrama de Objetos é muito similar ao Diagrama de Classes e utiliza quase a mesma notação.

Também possibilita a descrição de cenários de execução.


Diagrama de Estados

Serve para mostrar todos os estados possíveis dos objetos de um classe do modelo, e que eventos do sistema causam essas mudanças de estado.


Diagrama de Seqüência

Mostra a interação entre os objetos da aplicação arranjados numa linha do tempo.


Diagrama de Colaboração

O Diagrama de Colaboração é semelhante ao Diagrama de Seqüência, mostrando a colaboração dinâmica entre os objetos, sem levar em conta a linha do tempo.

Neste diagrama, além da troca de mensagens, pode-se perceber o relacionamento entre os objetos.


Diagrama de Componentes

O Diagrama de Componentes mostra o lado funcional, expondo a relação entre seus componentes e suas dependências.


Diagrama de Execução / Deployment

O Diagrama de Execução mostra o lado funcional, exibindo a arquitetura física do hardware e do software do sistema.

Análise (I)

Documents

Transcript of Análise (I)