professor m rio dantas
Download
Skip this Video
Download Presentation
Professor Mário Dantas

Loading in 2 Seconds...

play fullscreen
1 / 63

Professor Mário Dantas - PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on

Análise Orientada a Objetos. Fev /2011. Professor Mário Dantas. Aula 02 - Agenda. Paradigmas de Programação Processo de Desenvolvimento de Software Ferramentas de Apoio. Software Deselegante. O software deselegante é aquele software feito sem uma estrutura clara .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Professor Mário Dantas' - iria


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
professor m rio dantas
Análise Orientada a Objetos

Fev/2011

Professor MárioDantas

aula 02 agenda
Aula 02 - Agenda
  • Paradigmas de Programação
  • Processo de Desenvolvimento de Software
  • Ferramentas de Apoio
software deselegante
Software Deselegante
  • O software deselegante é aquele software feito sem uma estrutura clara.
  • O software deselegante é aquele do qual não se consegue reusar partes e que não se consegue entender como funciona sem uma boa carga de documentação (e muitas vezes nem assim).
  • É aquele no qual uma pequena modificação em uma de suas características pode causar um não funcionamento generalizado.
software elegante
Software Elegante
  • O software elegante é o software cuja estrutura é intrinsecamente mais fácil de compreender, é auto documentado e pode ser compreendido em nível macro ou em detalhes.
  • Ele é mais fácil de modificar: quando alguma de suas características é mudada, ele continua funcionando.
  • Soluções para prover elegância -> Padrões de Projeto – lições aprendidas ao longo dos anos em diferentes projetos.
orienta o a objetos
Orientação a Objetos
  • Orientação a objetos (OO) é uma abordagem de programação que procura explorar nosso lado intuitivo. Os objetos da computação são análogos aos objetos existentes no mundo real.
  • No enfoque de OO, os átomos do processo de computação são os objetos que trocam mensagens entre si.
  • Essas mensagens resultam na ativação de métodos, os quais realizam as ações necessárias.
orienta o a objetos1
Orientação a Objetos
  • Os objetos que compartilham uma mesma interface, ou seja, respondem as mesmas mensagens, são agrupados em classes.
  • Objeto é algo dinâmico: é criado por alguém, tem uma vida, morre ou é morto por alguém. Assim durante a execução do sistema, os objetos podem:
    • Ser construídos
    • Executar ações
    • Ser destruídos
    • Tornar-se inacessíveis
problemas do paradigma procedural
Problemas do paradigma procedural
  • Consideremos o clássico problema da validação de um CPF.
  • Normalmente, temos um formulário, no qual recebemos essa informação, e depois temos que enviar esses caracteres para uma função que irá validá-lo, como no pseudo-código abaixo:

cpf = formulario->campo_cpf

valida(cpf)

problemas do paradigma procedural1
Problemas do paradigma procedural
  • Alguém te obriga a sempre validar esse CPF?
  • Você pode, inúmeras vezes, esquecer de chamar esse validador.
  • Mais: considere que você tem 50 formulários e precise validar em todos eles o CPF.
  • Se sua equipe tem 3 programadores trabalhando nesses formulários, quem fica responsável por essa validação?
  • Todos!
problemas do paradigma procedural2
Problemas do paradigma procedural
  • A situação pode piorar: na entrada de um novo desenvolvedor.
  • É nesse momento que nascem aqueles guias de programação - às vezes, é um documento enorme.
  • Em outras palavras, todo desenvolvedor precisa ficar sabendo de uma quantidade enorme de informações, resultando um entrave muito grande!
problemas do paradigma procedural3
Problemas do paradigma procedural
  • Outra situação é quando nos encontramos na necessidade de ler o código que foi escrito por outro desenvolvedor e descobrir como ele funciona internamente.
  • Um sistema bem encapsulado não deveria gerar essa necessidade. Em um sistema grande, simplesmente não temos tempo de ler todo o código existente.
problemas do paradigma procedural4
Problemas do paradigma procedural
  • Considerando que você não erre nesse ponto e que sua equipe tenha uma comunicação muito boa, ainda temos outro problema:
    • imagine que, agora, em todo formulário, você também quer que a idade do cliente seja validada - o cliente precisa ter mais de 18 anos.
    • Vamos ter de colocar um if... mas onde? Espalhado por todo seu código... Mesmo que se crie outra função para validar, precisaremos incluir isso nos nossos 50 formulários já existentes.
  • Qual é a chance de esquecermos em um deles?
  • É muito grande.
problemas do paradigma procedural5
Problemas do paradigma procedural
  • Melhor ainda seria se conseguíssemos mudar essa validação e os outros programadores nem precisassem ficar sabendo disso.
  • Eles criariam formulários e um único programador seria responsável pela validação: os outros nem sabem da existência desse trecho de código. Impossível?
  • Não, o paradigma da orientação a objetos facilita tudo isso.
problemas do paradigma procedural6
Problemas do paradigma procedural
  • O problema do paradigma procedural é que não existe uma forma simples de criar conexão forte entre dados e funcionalidades.
  • No paradigma orientado a objetos é muito fácil ter essa conexão através dos recursos da própria linguagem.
vantagens de oo
Vantagens de OO
  • Abstração de dados: os detalhes referentes às representações das classes serão visíveis apenas a seus atributos;
  • Compatibilidade: as heurísticas para a construção das classes e suas interfaces levam a componentes de software que são fáceis de combinar;
  • Diminuiçãoda complexidade: as classes delimitam-se em unidades naturais para a alocação de tarefas de desenvolvimento de software.
vantagens de oo1
Vantagens de OO
  • Reutilização: o encapsulamento dos métodos e representação dos dados para a construção de classes facilitam o desenvolvimento de software reutilizável, auxiliando na produtividade de sistemas;
  • Extensibilidade: facilidade de estender o software devido a duas razões:
    • Herança: novas classes são construídas a partir das que já existem;
    • As classes formam um estrutura fracamente acoplada, o que facilita alterações;
  • Manutenibilidade: a modularização natural em classes facilita a realização de alterações no software.
vantagens de oo2
Vantagens de OO
  • Maior dedicação à fase de análise, preocupando-se com a essência do sistema;
  • Mesma notação é utilizada desde a fase de análise até a implementação.

Frente a essas vantagens, a abordagem OO tem se mostrado “popular” e eficaz.

processo de desenvolvimento
Processo de Desenvolvimento
  • O que é um processo de desenvolvimento?
    • É a definição de quem faz o que, quando e como, para atingir um certo alvo.
  • UML é uma linguagem de modelagem, não é uma metodologia. Não se consegue fazer uma boa modelagem sem conhecer processos.
  • Linguagem de modelagem + processo de desenvolvimento = método (ou metodologia) de desenvolvimento.
processo de desenvolvimento1
Processo de Desenvolvimento
  • As grandes fases de qualquer processo de desenvolvimento são:
    • Planejamento e elaboração
      • Planejamento, definição de requisitos, construção de protótipos (opcional)
    • Construção do sistema (inclui codificação e testes)
    • Implantação (colocar em produção, treinar usuários, ...)
processo de desenvolvimento2
Processo de Desenvolvimento
  • UML não depende de processo. Você deve escolher o que for adequado ao seu projeto.
  • Existem diversos modelos, e esse modelos são influenciados por alguns fatores como:
    • Tipo de software que será desenvolvido (real-time, sistema de informação, etc.)
    • Escala (Um desenvolvedor, equipe pequena, etc.)
processo de desenvolvimento3
Processo de Desenvolvimento
  • Modelo em Cascata
  • Modelo de Prototipagem
  • Modelo Evolucionário
  • Desenvolvimento Baseado em Componentes
  • Modelo de Métodos formais
  • Programação Extrema
  • Processo Unificado
processo unificado
Processo Unificado
  • O processo unificado (PU) de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos do usuário em um sistema de software.
  • É fundamental na visão de que o avanço de um projeto deve estar baseado na construção de artefatos de software, e não apenas em documentação.
processo unificado1
Processo Unificado
  • A motivação para o uso da abordagem de CraigLarmanao Processo Unificado deve-se ao fato de que este é um processo bastante conciso e eficiente para análise e projeto de sistemas orientado a objetos
  • Neste método, cada artefato (documento ou diagrama) tem uma razão muito clara para existir e as conexões entre os diferentes artefatos são muito precisas.
processo unificado2
Processo Unificado
  • Principais Características:
    • Dirigido por casos de uso.
      • Descrições de casos de uso e seus diagramas embasam a construção do software.
    • Centrado na arquitetura.
      • O documento visão, diagrama de componentes e implantação, diagrama de interação e diagrama de classes (modelo de dados) fornecem a perspectivas da arquitetura do software.
    • Iterativo e incremental.
dirigido por casos de uso
Dirigido por casos de uso
  • Um caso de uso é uma seqüência de ações, executadas por um ou mais atores e pelo próprio sistema, que produz um ou mais resultados de valor para um ou mais atores.
  • O PU é dirigido por casos de uso, pois utiliza-os para dirigir todo o trabalho de desenvolvimento, desde a captação inicial e negociação dos requisitos até a aceitação do código (testes).
dirigido por casos de uso1
Dirigido por casos de uso
  • Os casos de uso são centrais ao PU e a outros métodos iterativos, pois:
    • Os requisitos funcionais são registrados preferencialmente por meio deles;
    • Eles ajudam a planejar as iterações;
    • Eles podem conduzir o projeto;
    • O teste é baseado neles.
centrado na arquitetura
Centrado na arquitetura
  • Arquitetura é a organização fundamental do sistema como um todo. Inclui elementos estáticos, dinâmicos, o modo como trabalham juntos e o estilo arquitetônico total que guia a organização do sistema.
  • A arquitetura também se refere a questões como desempenho, escalabilidade, reuso e restrições econômicas e tecnológicas.
centrado na arquitetura1
Centrado na arquitetura
  • No PU, a arquitetura do sistema em construção é o alicerce fundamental sobre o qual ele se erguerá.
  • Deve ser uma das preocupações da equipe de projeto.
  • A arquitetura, juntamente com os casos de uso, deve orientar a exploração de todos os aspectos do sistema.
centrado na arquitetura2
Centrado na arquitetura
  • A arquitetura é importante porque:
    • Ajuda a entender a visão global;
    • Ajuda a organizar o esforço de desenvolvimento;
    • Facilita as possibilidades de reuso;
    • Facilita a evolução do sistema;
    • Guia a seleção e exploração dos casos de uso.
desenvolvimento iterativo
Desenvolvimento Iterativo
  • O desenvolvimento de um software dividido em vários ciclos de iteração, cada qual produzindo um sistema testado, integrado e executável.
  • Em cada ciclo ocorrem as atividades de análise de requisitos, projeto, implementação e teste, bem como a integração dos artefatos produzidos com os artefatos já existentes.
desenvolvimento iterativo1
Desenvolvimento Iterativo
  • Planejar quantos ciclos de desenvolvimento serão necessários para alcançar os objetivos do sistema.
  • As partes mais importantes devem ser priorizadas e alocadas nos primeiros ciclos.
    • A primeira iteração estabelece os principais riscos e o escopo inicial do projeto, de acordo com a funcionalidade principal do sistema.
    • Partes mais complexas do sistema devem ser atacadas já no primeiro ciclo, pois são elas que apresentam maior risco de inviabilizar o projeto.
desenvolvimento iterativo2
Desenvolvimento Iterativo
  • O tamanho de cada ciclo pode variar de uma empresa para outra e conforme o tamanho do sistema.
    • Por exemplo, uma empresa pode desejar ciclos de 4 semanas, outra pode preferir 3 meses.
    • Produtos entregues em um ciclo podem ser colocados imediatamente em operação, mas podem vir a ser substituídos por outros produtos mais complexos em ciclos posteriores.
trabalhadores
Trabalhadores
  • Trabalhadores: Um trabalhador é alguém que desempenha um papel e é responsável pela realização de atividades para produzir ou modificar um artefato.
  • Exemplos: analista de sistemas, programador, testador, etc.
atividades
Atividades
  • Atividades: tarefa que um trabalhador executa a fim de produzir ou modificar um artefato.
processos do pu
Processos do PU
  • Descreve as seqüências das atividades que produzem algum resultado significativo e mostra as interações entre os participantes
  • São realizadas a qualquer momento durante o ciclo de desenvolvimento (Fases do PU)
  • Ex.:
    • Requisitos, Análise, Projeto, Implementação e Teste
processos do pu1
Processos do PU
  • Conjunto de atividades (e artefatos relacionados):
    • Modelagem de Negócio
    • Requisitos
    • Projeto
    • Implementação
    • Teste
    • Implantação
    • Gestão de Configuração e Mudanças
    • Gerenciamento de projeto
    • Ambiente
fases do processo unificado
Fases do Processo Unificado
  • Cada um dos ciclos de desenvolvimento do PU é dividido em quatro fases:
    • Concepção;
    • Elaboração;
    • Construção;
    • Transição.
fases do pu concep o
Fases do PU: Concepção
  • Estabelece-se a viabilidade de implantação do sistema.
  • Definição do escopo do sistema.
  • Estimativas de custos e cronograma.
  • Identificação dos potenciais riscos que devem ser gerenciados ao longo do projeto.
  • Esboço da arquitetura do sistema, que servirá como alicerce para a sua construção.
fases do pu elabora o
Fases do PU: Elaboração
  • Visão refinada do sistema:
    • definição dos requisitos funcionais;
    • detalhamento da arquitetura criada na fase anterior;
    • gerenciamento contínuo dos riscos envolvidos.
  • Estimativas realistas feitas nesta fase permitem um plano para orientar a construção do sistema.
fases do pu constru o
Fases do PU: Construção
  • O sistema é efetivamente desenvolvido e, em geral, tem condições de ser operado, mesmo que em ambiente de teste, pelos clientes.
fases do pu transi o
Fases do PU: Transição
  • O sistema é entregue ao cliente para uso em produção.
  • Testes são realizados e um ou mais incrementos do sistema são implantados.
  • Defeitos são corrigidos, se necessário.
processos do pu2
Processos do PU
  • Avaliando-se as fases do PU, pode-se ter a impressão de que cada ciclo de iteração comporta-se como o modelo em cascata.
  • Mas isso não é verdade: paralelamente às fases do PU, as atividades de trabalho, denominados Processos do PU, são realizadas a qualquer momento durante o ciclo de desenvolvimento.
  • Processos do PU entrecortam todas as fases do PU, podendo ter maior ênfase durante certas fases e menor ênfase em outras, mas podendo ocorrer em qualquer uma delas.
os artefatos do pu
Os Artefatos do PU
  • Cada uma das disciplinas do PU pode gerar um ou mais artefatos, que devem ser controlados e administrados corretamente durante o desenvolvimento do sistema.
  • Artefatos são quaisquer dos documentos produzidos durante o desenvolvimento, tais como modelos, diagramas, documentos de especificação de requisitos, código fonte ou executável, planos de teste, etc.
  • Muitos dos artefatos são opcionais, produzidos de acordo com as necessidades específicas de cada projeto.
os artefatos do pu1
Os Artefatos do PU

P = produzir R = revisar

ferramentas
Ferramentas
  • O que são Ferramentas CASE?
  • A sigla CASE significa “Computer-Aided Software Engineering”.
  • Traduzindo para um bom português: “Engenharia de Software Auxiliada por Computador”.
ferramentas1
Ferramentas
  • As ferramentas se dividem em três categorias. São elas:
  • LowerCASE- ferramentas de codificação (front-end);
  • UpperCASE- ferramentas de análise, projeto e implementação;
  • IntegratedCASE- união de Upper e Lower CASE.
ferramentas2
Ferramentas
  • Como escolher a ferramenta?
  • O primeiro passo é saber qual será o uso da ferramenta na sua empresa. Isto é, ferramenta para codificação ou ferramenta para análise.
  • Outro fator importante é que a ferramenta deve ser aderente ao conceitos de trabalho na sua empresa.Como estes conceitos e técnicas evoluem no tempo.
ferramentas3
Ferramentas
  • Questões importantes para escolha da ferramenta:
    • O time de desenvolvimento está preparado tecnicamente para trabalhar com ferramentas case?
    • Preciso capacitar os recursos humanos de minha empresa?
    • A metodologia de desenvolvimento em minha empresa está “amadurecida”?
ferramentas4
Ferramentas
  • Na prática, as ferramentas existentes no mercado possuem as características das quais destacam-se os seguintes pontos:
    • Desenvolvidas sobre uma arquitetura inteligente (customizável);
    • Possuem "facilitadores" para auxiliar nas tarefas repetitivas;
    • Verificação da consistência através de regras específicas;
    • Geração de relatórios para acompanhamento do trabalho;
    • Interfaces com outros aplicativos de desenvolvimento.
ferramentas5
Ferramentas

“Uma ferramenta CASE não é a solução para todos os problemas da organização. A organização deve ter certeza de estar pronta para a nova ferramenta. Desta forma uma ferramenta só deveria ser selecionada após a definição do processo de desenvolvimento, dos métodos e de ter sido utilizada num projeto piloto.” (Reid).

ferramentas6
Ferramentas
  • Comerciais e “FreeEditions”
    • MagicDraw ($ 1,599,00)
    • Together Architect  ( $ 11.500,00)
    • Poseidon ($ 875,00 )
    • Enterprise Architect ($ 2.500,00)
    • Rose Technical Developer ($6,880.00)
    • Jude/Astah ($280,00 1usuário/1ano)
    • Omondo Eclipse UML ($ 84,900.00 / 20 usuários)
    • Visual Paradigm ($ 699)

Fonte: http://www.objectsbydesign.com/tools/umltools_byPrice.html

ferramentas7
Ferramentas
  • Livres (BSD e GPL)
    • Umbrello
    • ArgoUML
    • Dia
    • BOUML
    • Fajuba
    • StarUML
slide60
Dia é um programa baseado em gtk+ para criação do diagrama, liberado sob a licença GPL.
  • É parte do projeto Gnome.
  • Atualmente tem objetos especiais de lógica, entidade e relacionamento, diagramas UML, fluxogramas, diagramas da rede, e circuitos simples entre outros.
argouml
ArgoUML
  • ArgoUML é uma ferramenta CASE baseada na notação UML (UnifiedModelingLanguage).
  • Foi desenvolvido pela comunidade de desenvolvedores de código livre Tigris vinculada a Universidade da California, Berkeley.
  • Sua interface é bem completa o que a torna um pouco complexa de manipular.
slide62
Umbrello e um Software de Modelagem UML, que e integrado ao projeto KDE.
  • Este Software é utilizado para modelar o próprio projeto do KDE por a grande de seus desenvolvedores que utilizam UML.
slide63
JUDE é uma ferramenta profissional de modelagem para sistemas a qual suporta UML, diagrama entidade relacionamento, Flowchart, CRUD, Mini Mapas e Diagrama de Fluxo de Dados.
  • Permite também a conversão entre modelos UML, ER Diagramas, Flowcharts, fluxo de dados e mini mapas.
  • O nome do programa é um acrônimo de Java andUML DevelopersEnvironment (Ambiente para Desenvolvedores UML e Java).
ad