Professor m rio dantas
Download
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


  • 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.


  • 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.


  • 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