Engenharia de Software - Parte 3

(1)

Eng. de Software - Fabiana Costa Guedes 1

Métodos e Técnicas de Desenvolvimento

de Sistemas Orientados a Objetos

(2)

Eng. de Software - F abiana Costa Guedes

2

Processo de Desenvolvimento

com Orientação a Objetos



Podemos descrever o problema e sua

solução em termos de classes,

objetos, métodos, atributos e

comportamentos.



A representação orientada a objetos

requer 3 perspectivas: estática,

dinâmica e restritiva.

(3)

3

Processo de Desenvolvimento

com Orientação a Objetos



Visões estáticas: incluem as descrições de

objetos, os atributos, comportamentos e

relacionamentos.



Visões dinâmicas: descrevem a

comunicação, o controle/sincronia, bem

como os estados e suas mudanças.



Visões Restritivas: descrevem as limitações

(4)

4

Processo de Desenvolvimento

com Orientação a Objetos



A consistência ao longo do projeto é a

principal diferença entre o desenvolvimento

procedural e o processo de

desenvolvimento orientado a objetos.



A OO lida com requisitos, projetos de nível

alto e baixo, codificação e testes, mas não

de maneira sequencial.



A seqüência é determinada pelo Ciclo de

(5)

5

Linguagem Tradicional x OO

Linguagem Tradicional possuem foco nos programas, responsáveis pela parte ativa da aplicação.

Nas Linguagem OO, os dados são protegidos por uma cápsula, na qual residem procedimentos que intermedeiam o acesso a eles.

Procedimento 1 Procedimento 2 Procedimento 3 Dados Métodos Dados Métodos Dados Métodos Dados Objeto

(6)

6

Principais características da

Análise OO



Resolução de domínio de

problemas mais amplos:

Relacionamentos complexos entre os

objetos.



Melhoria na interação entre o

analista e o usuário: OO técnica de

abstração, aproximando o modelo do

sistema do mundo real do usuário.

(7)

7

Principais características da

Análise OO



Aumento da consistência interna da

análise: A OO reduz as distâncias

entre as diferentes atividades de

análise, tratando dados e processos

como um todo.



Representação explícita dos pontos

e métodos em comuns: herança.



Reusabilidade: Favorece a

(8)

8

Principais características da

Análise OO



Elaboração de especificações que

suportam alterações: Sistemas mais

flexíveis, onde alterações de alto nível

conceitual podem ser propagadas.



Abordagem incremental e evolutiva:

pequenas modificações podem ser

rapidamente efetuadas e testadas ->

Novas classes ou especialização das

existentes.

(9)

9

Tópicos para Discussão



Como funciona o Processo de

Desenvolvimento com OO?



Fale sobre as Perspectivas (visões)

 Estáticas;  Dinâmicas;  Restritivas.

(10)

10

Tópicos para Discussão



Linguagem Tradicional X OO



Quais são as principais características da

(11)

Método Unified Process (UP) de

Desenvolvimento de Sistemas

(12)

12

UP – Processo Unificado

 Surgiu como um processo popular para o

desenvolvimento de software visando à construção de sistemas orientados a objetos.

 Refinamentos e incrementos de um sistema por meio de múltiplas iterações, com realimentação (feedback) e adaptação cíclicas

 Desenvolvimento Iterativo – séries de mini-projetos de duração fixa chamada iterações. O produto é um sistema testado, integrado e executável. Cada Iteração inclui suas próprias atividades de análise de requisitos, projeto,

(13)

13

Iteração



Escolha de um subconjunto dos

requisitos.



Realimentação rápida



Atitude de aceitar a mudança e a

adaptação como fatores inevitáveis e

de fato essenciais.



Processo de “sim – mas” – modo hábil de

progredir e descobrir o que é de real

valor para os interessados no sistema.

(14)

14

Iteração



Indicativo do caminho certo ou se na

iteração seguinte será necessária uma

mudança na arquitetura principal do

sistema.



Um processo que aceita a mudança e

a realimentação como fatores centrais

na descoberta de requisitos.

(15)

15

(16)

16

Artefato



É o termo usado para qualquer

produto do trabalho.



O objetivo não é o documento ou

diagrama em si, mas o raciocínio,

a análise e a presteza proativa

evitando sua reinvenção ou

repetição verbal.

(17)

17

Artefatos



Tipos de Artefatos:



Código.



Gráficos



Esquema de banco de dados.



Documentos em texto



Diagramas

(18)

18

(19)

19

Benefícios do

Desenvolvimento Iterativo



Mitigação precoce de altos riscos



Progresso visível desde o início.



Realimentação - sistema refinado.



Complexidade é administrada, evita

“paralisia da análise”



O aprendizado obtido em uma iteração

pode ser usado para melhorar o

próprio processo.

(20)

20

Melhores Práticas



Iterações curtas com duração fixa em um

processo de desenvolvimento iterativo

adaptativo.



Uso de tecnologias orientadas a objetos.



Enfrentar os problemas que envolvem altos

riscos e alto valor já nas iterações iniciais.



Envolver continuamente os usuários na

avaliação, na realimentação e nos

requisitos.



Construir uma arquitetura central coesa nas

(21)

21

Melhores Práticas



Verificar continuamente a qualidade,

fazer testes logo de início.



Aplicar casos de uso.



Modelar visualmente o software –

UML



Gerenciar requisitos cuidadosamente.



Usar solicitações de mudança e

(22)

22

FASES



CONCEPÇÃO:



As necessidades dos usuários e

conceitos da aplicação são analisados

para justificar a especificação de um

produto de Software.



Visão aproximada, casos de negócio,

(23)

23

FASES



CONCEPÇÃO:



Estudo de viabilidade – decisão

de continuar ou parar.



Resultado: Proposta de

(24)

24

FASES



ELABORAÇÃO:



A Especificação do produto é

detalhada o suficiente para

modelar conceitualmente o

domínio do problema.

(25)

25

FASES



ELABORAÇÃO:



Visão refinada, implementação

iterativa da arquitetura central,

resolução dos altos riscos,

identificação da maioria dos requisitos

e do escopo e estimativas mais

realistas.



Validar requisitos de acordo com o

(26)

26

FASES



CONSTRUÇÃO:



É desenvolvida – Desenhada,

Implementada e Testada – uma

liberação operacional do produto.



Deve atender aos requisitos

(27)

27

FASE



TRANSIÇÃO:



O produto é colocado a disposição

de uma comunidade de usuários

para testes finais, treinamento e uso

inicial.

(28)

28

FLUXOS



Requisitos: Visa obter um conjunto de

requisitos de um produto, definidos de

acordo com desenvolvedor e cliente.



Análise: Visa detalhar, estruturar e

validar os requisitos por meio de um

modelo conceitual. Serve de base

para a construção do produto.

(29)

29

FLUXOS



Desenho/Projeto: Visa formular

um modelo estrutural do produto

que sirva de base para a

implementação. Define

componentes a serem

desenvolvidos e reutilizados e

interfaces interna e externas (com

o contexto do produto).

(30)

30

FLUXOS



IMPLEMENTAÇÃO: Visa detalhar e

implementar o desenho por meio de

componentes de código e de

documentação associada.



TESTES: Visa verificar os resultados

da implementação, por meio do

planejamento, desenho e realização

de bateria de testes.

(31)

31

Rational Unified Process

(RUP)



Concretizações do Processo Unificado –

RUP (Rational)



Tem estrutura de fluxos diferentes (combina

fluxos de Análise e Desenho)



Possui fluxos gerenciais adicionais

 Modelagem de negócios, implantação, gestão

de configurações e alterações, gestão de projetos e ambiente

(32)

32

Rational Unified Process

(RUP)

O RUP foi desenvolvido baseado no Unified Process (IEEE), nas

(33)

33

Rational Unified Process

(RUP)



Fases do RUP:

 Concepção - definição do escopo a partir da

análise de requisitos, definição de tempo e custo para implementação do sistema, identificação dos principais casos de uso;

 Elaboração - refinamento dos requisitos,

elaboração do diagrama de classes, definição da arquitetura (2 ou 3 camadas, XML,

(34)

34

Rational Unified Process

(RUP)



Fases do RUP:



Construção - implementação do código a

partir da documentação da fase de

elaboração.



Transição - disponibilizar o sistema para

o usuário que compreende configurações

do ambiente de produção, das estações

de trabalho, treinamento do usuário.

(35)

35

Tópicos para Discussão

 Processo Unificado

 Iteração  Artefato

 Ciclo de Desenvolvimento UP

 Benefícios do Desenvolvimento Iterativo  Melhores Práticas

 Fases e Fluxos do UP  RUP

(36)

Outros Processos de

Desenvolvimento

(37)

37

Planejamento Preditivo



Uma estratégia preditiva procura fazer o

trabalho antecipadamente no projeto, a

fim de gerar um maior entendimento do

que precisa ser feito posteriormente.



Você pode chegar a um ponto onde a

última parte do projeto pode ser estimada

com um grau de precisão razoável.

(38)

38

Planejamento Preditivo



O projeto possui dois estágios:



O primeiro sugere planos e é difícil de

prever;



O segundo é muito previsível pois os

planos estão estabelecidos.



À medida que o projeto evolui você

(39)

39

Planejamento Preditivo



Podem ocorrer desvios, porém,

espera-se que sejam menos

significativos, quando um plano sólido

estiver estabelecido.



O grande problema deste processo é

(40)

40

Planejamento Preditivo



Uma solução é elaborar melhor o

processo de especificação de

requisitos em si. Pode-se obter um

conjunto de requisitos mais preciso, o

que reduzirá a alteração.



Outra prevê que a alteração de

requisitos é inevitável e defende o

(41)

41

Planejamento Adaptativo



Devemos encarar a realidade da alteração

constante e utilizar uma estratégia de

planejamento que trata a alteração como

uma constante em um projeto de software.



A alteração é controlada para que o

projeto gere o melhor software possível.



Embora o projeto seja controlado, ele não

(42)

42

Planejamento Adaptativo



Os projetos adaptativos possuem um

planejamento, mas o plano é tratado

como uma linha de base para avaliar

as conseqüências da alteração, em

vez de tratá-lo como uma previsão do

futuro.

(43)

43

Processos Ágeis



Ágil é um termo abrangente que

compreende muitos processos que

compartilham um conjunto comum de

valores e de princípios, conforme definido

pelo Manifesto of Agile Software

Development.



Ex.: Extreme Programming (XP), Scrum,

FDD (Feature Driven Development), Crystal

e DSDM (Dynamic Systems Development

Method).

(44)

44

Processos Ágeis



São fortemente adaptativos por

natureza.



Muito voltado às pessoas – o sucesso

está na qualidade das pessoas

envolvidas e o quão bem elas

trabalham juntas, em termos

humanos.

(45)

45

Processos Ágeis



As metodologias tendem a utilizar

iterações curtas e com quadro de

tempo estabelecido.



Como não associam muito peso aos

documentos, desprezam o uso da

UML no projeto.

(46)

46

Processos Ágeis



Tendem a ter pouca formalidade.



Consideram que a formalidade torna mais

difícil fazer alterações e vão contra a

natureza das pessoas talentosas.



A falta de formalidade é uma conseqüência

da adaptabilidade e da orientação das

pessoas, em vez de ser uma propriedade

fundamental.

(47)

47

Tópicos para Discussão



Planejamento Preditivo

