professor mário dantas
DESCRIPTION
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 . - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/1.jpg)
Professor Mário Dantas
ANÁLISE ORIENTADA A OBJETOSFev/2011
![Page 2: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/2.jpg)
Aula 02 - Agenda Paradigmas de Programação Processo de Desenvolvimento de
Software Ferramentas de Apoio
![Page 3: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/3.jpg)
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.
![Page 4: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/4.jpg)
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.
![Page 5: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/5.jpg)
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.
![Page 6: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/6.jpg)
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
![Page 7: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/7.jpg)
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_cpfvalida(cpf)
![Page 8: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/8.jpg)
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!
![Page 9: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/9.jpg)
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!
![Page 10: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/10.jpg)
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.
![Page 11: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/11.jpg)
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.
![Page 12: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/12.jpg)
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.
![Page 13: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/13.jpg)
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.
![Page 14: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/14.jpg)
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ção da complexidade: as classes delimitam-se em unidades naturais para a alocação de tarefas de desenvolvimento de software.
![Page 15: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/15.jpg)
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.
![Page 16: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/16.jpg)
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.
![Page 17: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/17.jpg)
Classes
![Page 18: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/18.jpg)
Classes e Objetos
![Page 19: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/19.jpg)
PROCESSO DE DESENVOLVIMENTOAgo/2010
![Page 20: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/20.jpg)
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.
![Page 21: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/21.jpg)
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, ...)
![Page 22: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/22.jpg)
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.)
![Page 23: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/23.jpg)
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
![Page 24: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/24.jpg)
Processo em cascata
![Page 25: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/25.jpg)
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.
![Page 26: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/26.jpg)
Processo Unificado A motivação para o uso da abordagem
de Craig Larman ao 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.
![Page 27: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/27.jpg)
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.
![Page 28: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/28.jpg)
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).
![Page 29: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/29.jpg)
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.
![Page 30: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/30.jpg)
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.
![Page 31: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/31.jpg)
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.
![Page 32: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/32.jpg)
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.
![Page 33: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/33.jpg)
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.
![Page 34: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/34.jpg)
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.
![Page 35: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/35.jpg)
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.
![Page 36: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/36.jpg)
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.
![Page 37: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/37.jpg)
Atividades Atividades: tarefa que um trabalhador
executa a fim de produzir ou modificar um artefato.
![Page 38: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/38.jpg)
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
![Page 39: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/39.jpg)
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
![Page 40: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/40.jpg)
Fases do Processo Unificado Cada um dos ciclos de desenvolvimento
do PU é dividido em quatro fases: Concepção; Elaboração; Construção; Transição.
![Page 41: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/41.jpg)
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.
![Page 42: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/42.jpg)
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.
![Page 43: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/43.jpg)
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.
![Page 44: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/44.jpg)
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.
![Page 45: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/45.jpg)
Fases do Processo Unificado
• Visão do Software
• Tecnologia• Riscos• Áreas críticas
Concepção
• Requisitos em detalhes
Elaboração • Protótipos
• Codificação• Banco de Dados
Construção
• Avaliação do software
• Versão de Produção
Transição
![Page 46: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/46.jpg)
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.
![Page 47: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/47.jpg)
Processos do PU
Requisitos
Análise
ProjetoImplementação
Testes
![Page 48: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/48.jpg)
Processo Unificado
![Page 49: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/49.jpg)
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.
![Page 50: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/50.jpg)
Os Artefatos do PUDisciplina Artefato
InteraçãoConcepção Elaboração Construção Transição
Modelagem de Negócio
Modelo Conceitual ou Documento Visão
P
RequisitosDiagrama de Caso de Uso P R
Descrição de Caso de Uso P R
Diagrama de Seqüência P R
Contratos para operações P R
Glossário P R
AnáliseDiagrama de Classes P R
Diagrama de Colaboração P R
Diagrama de Pacotes P R
Documento de Arquitetura do Software
P R
Implementação Código Fonte P R
P = produzir R = revisar
![Page 51: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/51.jpg)
FERRAMENTAS DE APOIOAgo/2010
![Page 52: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/52.jpg)
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”.
![Page 53: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/53.jpg)
Ferramentas As ferramentas se dividem em três
categorias. São elas:1. Lower CASE - ferramentas de
codificação (front-end);2. Upper CASE - ferramentas de análise,
projeto e implementação;3. Integrated CASE - união de Upper e
Lower CASE.
![Page 54: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/54.jpg)
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.
![Page 55: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/55.jpg)
Ferramentas Questões importantes para escolha da
ferramenta:1. O time de desenvolvimento está
preparado tecnicamente para trabalhar com ferramentas case?
2. Preciso capacitar os recursos humanos de minha empresa?
3. A metodologia de desenvolvimento em minha empresa está “amadurecida”?
![Page 56: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/56.jpg)
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.
![Page 57: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/57.jpg)
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).
![Page 58: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/58.jpg)
Ferramentas Comerciais e “Free Editions”
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
![Page 59: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/59.jpg)
Ferramentas Livres (BSD e GPL)
Umbrello ArgoUML Dia BOUML Fajuba StarUML
![Page 60: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/60.jpg)
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.
![Page 61: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/61.jpg)
ArgoUML ArgoUML é uma ferramenta CASE
baseada na notação UML (Unified Modeling Language).
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.
![Page 62: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/62.jpg)
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.
![Page 63: Professor Mário Dantas](https://reader036.vdocuments.pub/reader036/viewer/2022081514/5681610e550346895dd0660a/html5/thumbnails/63.jpg)
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 and UML Developers Environment (Ambiente para Desenvolvedores UML e Java).