Download
1 / 43
430 likes | 583 Views
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;
E N D
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;
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áriosolicitam, 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.
Unified Modeling Language (UML) • 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.
Unified Modeling Language (UML) • 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.
Modelos de Elementos da 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.
Modelos de Elementos da UML • 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.
Modelos de Elementos da UML • 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
Modelos de Elementos da UML - Relacionamentos • 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.
Modelos de Elementos da UML - Relacionamentos • 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.
Modelos de Elementos da UML - Relacionamentos • 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.
Modelos de Elementos da UML - Relacionamentos 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. 28
Modelos de Elementos da UML - Relacionamentos 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. 29
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
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 (I)
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. 34
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 (I)
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. 38
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. 39
Diagrama de Seqüência • Mostra a interação entre os objetos da aplicação arranjados numa linha do tempo. 40
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. 41
Diagrama de Componentes • O Diagrama de Componentes mostra o lado funcional, expondo a relação entre seus componentes e suas dependências. 42
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. 43
