aula 001

www.tiparaconcursos.net facebook.com/tiparaconcursos twitter.com/gabrielfpacheco

[email protected]

Engenharia de Software

Análise e Projetos de

Sistemas OO -II

Teoria e Exercícios

Fowler / Booch / Jacobson /

Rumbaugh / Guedes / Cordeiro

1

http://www.tiparaconcursos.net

mailto:[email protected]

Conteúdo Programático.

Análise e projeto de sistemas:

Análise e projeto estruturado / Análise estruturada.

Análise e projeto OO.

Conceitos fundamentais.

Análise.

Modelagem.

Padrões de projeto.

UML.

5

Análise e projeto de SistemasEstruturado X OO

Estruturado:Foco no como fazer.

Inadequação entre o comportamento e a estrutura de dados.

Sensível a mudanças.

Sem noção de estrutura e responsabilidade.

Impossibilidade de medirmos o impacto de uma mudança.

6

Análise e projeto de SistemasEstruturado X OO

OO:Foco no que fazer.

Estrutura de dados e comportamento em mesmo modelo.

Estrutura de responsabilidade definida.

Pode-se medir o impacto de uma mudança.

7

Análise e projeto de SistemasModelos OO

Procedimentos de concepção de sistemas a partir dos conceitos de OO.

Corresponde às principais fases de um ciclo de vida de software genérico.

Especificação de software.

Projeto e implementação de software.

Validação de software.

Evolução de software.

8


OMT – Object Modelling Tecnique:4 fases: análise, projeto de sistema, projeto de objetos e implementação.

Fase de análise com 3 diagramas que representam os modelos de objeto, dinâmico e funcional.

Booch:Baseado em 3 fases: análise de requisitos, análise de domínios e projetos.

Trabalhando com os diagramas: de classes, de transição de estados, de objetos, temporais, de módulos e de processos.

9


Coad/Yourdon: utiliza um modelo único para OOA, OOD e OOP.

Shlaer/Mellor: conjunto integrado de modelos de análise e que depois são traduzidos durante o projeto.

OOSE (Jacobson): centrado em UCs com aprofundamento no andar da carroagem.

Fusão (OMT e Jacobson): integração entra OMT e Booch.

UML: Unificação do OMT, Booch e OOSE.

10

Análise e projeto de SistemasPOO – Modelagem Orientada a Objeto

Abstração com propósito de entender um problema antes de solucioná-lo.

Possibilita a simulação e testes de um sistema antes mesmo dele ser construído.

Facilita a comunicação entre usuários e membros da equipe de desenvolvimento.

11

Análise e projeto de SistemasPOO – Modelagem Orientada a Objeto

OMT:Modelo Objeto: aspectos estáticos, estruturais, dados do sistema.

Modelo Dinâmico: aspectos temporais, comportamentais, controle do sistema.

Modelo Funcional: representa os aspectos transformacionais e de função de um sistema.

Todos eles estão interconectados, depende do nível de abstração que está sendo utilizado.

12

Análise e projeto de SistemasPOO – Análise e Projeto OO

Abordagem RUP X UML.Análise Orientada a Objetos: desenvolvimento de um modelo orientado a objetos do domínio da aplicação. Devem refletir as entidades e as operações associadas ao problema a ser resolvido.

Projeto Orientado a Objetos: desenvolvimento de um modelo orientado a objetos de um sistema. Os objetos deverão estar relacionados à solução do problema.

Programação Orientada a Objeto: realizar um projeto de software usando uma linguagem de programação orientada a objetos.

A transição entres estes estágios deve ser contínua com notações compatíveis a cada estágio.

13

Análise e projeto de Sistemas Rational Unified Process - RUP

Descrito a partir de três perspectivas:

Dinâmica – fases do modelo ao longo do tempo.

Estática – atividades realizadas no processo.

Prática – boas práticas a serem usadas durante o processo.

14


15


Modelo constituído por 4 fases discretas:

Concepção: estabelecer um business case para o sistema. Avaliação do ambiente de negócio em relação à contribuição de um sistema para o negócio. (escopo)

Elaboração: desenvolver um entendimento do domínio do problema, estabelecer um framework, desenvolver um plano de projeto e identificar os riscos principais do projeto. (modelo de requisitos para o sistema).(arquitetura).

16


Modelo constituído por 4 fases discretas:

Construção: relacionada ao projeto, programação e teste de sistema. As partes são desenvolvidas separadamente e integradas. Software funcional + documentação. (desenvolvimento)

Transição: fase final do RUP. Transferência do desenvolvimento para o usuário. Entrada do sistema em produção. Fase onerosa e problemática. (implantação).

17


Cada fase pode ser realizada de forma iterativa, com resultados desenvolvidos incrementalmente.

O conjunto total de fases pode ser realizada de forma incremental.

18


Visão estática do RUP (os Workflows):Fases são dinâmicas e tem objetivos.

Workflows são estáticos e constituem atividades técnicas que não estão associadas a uma única fase.

As fases não estão associadas aos workflows específicos.

19


Visão estática do RUP (os Workflows):Modelagem de negócios: processos de negócio são modelados usando casos de uso de negócios.

Requisitos: agentes que interagem com o sistemas são identificados e os UCs são desenvolvidos para modelar os requisitos de sistema.

Análise e projeto: modelo de projeto é criado e documentado usando modelos de arquitetura, modelos de componente, modelos de objeto e modelos de sequencia.

Implementação: componentes de sistema são implementados e estruturados em subsistemas de implementação.

20


Visão estática do RUP (os Workflows):Teste: processo iterativo realizado em conjunto com a implementação.

Implantação: versão do produto é criada, distribuída aos usuários e instalada.

Gerenciamento de configuração e mudanças: gerencia as mudanças do sistema.

Gerenciamento de projetos: gerencia o desenvolvimento do sistema.

Ambiente: está relacionado à disponibilização de ferramentas apropriadas de software para a equipe de desenvolvimento.

21


O RUP recomenda 6 melhores práticas fundamentais (linhas mestras):

Desenvolver o software iterativamente: incrementos de software priorizados e entregues.

Gerenciar requisitos: documentação e acompanhamento das mudanças dos requisitos.

Usar arquiteturas baseadas em componentes: estruturar a arquitetura de sistema de componentes.

Modelar o software visualmente: modelos gráficos UML.

Verificar a qualidade do software: atendam aos padrões de qualidade da organização.

Controlar as mudanças do software: usando um SGM e procedimentos.

22

Análise e projeto de Sistemas RUP – Desenvolvimento Iterativo

Ciclo de vida que consiste em várias iterações.

Cada iteração incorpora um conjunto quase sequêncial de atividades em modelagem de negócios, requisitos, análise de projeto, implementação, teste e implantação.

23


24


Riscos detectados e tratados mais cedo, pois os elementos são integrados progressivamente.

A melhora o refinamento do produto.

Melhoria de seus processos.

Aumento da capacidade de reutilização.

25

Análise e projeto de Sistemas RUP – Gerenciamento de Requisitos

Requisito: Uma condição ou capacidade com a qual o sistema deverá estar em conformidade.

Descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais.

Reflete as necessidades dos clientes de um sistema que ajuda a resolver algum problema.

26


Gerenciamento de Requisitos:Abordagem sistemática para localizar, documentar, organizar e controlar os requisitos de um sistema.

As chaves para o gerenciamento eficaz de requisitos incluem manter uma sentença clara dos requisitos, junto com os atributos aplicáveis e a rastreabilidade para outros requisitos e outros artefatos do projeto.

27


Dificuldades na coleta de Requisitos:Nem sempre os requisitos são óbvios e podem vir de várias fontes.

Existem diversos tipos de requisitos em diferentes níveis de detalhe.

O número de requisitos pode se tornar impossível de gerenciar se eles não forem controlados.

Os requisitos estão relacionados uns com os outros, e também com o produto liberado do processo de engenharia do software.

Os requisitos têm propriedades exclusivas ou valores de propriedade. Por exemplo, eles não são necessariamente igualmente importantes ou igualmente fáceis de se atender.

Há várias partes interessadas, o que significa que os requisitos precisam ser gerenciados por grupos de pessoas de diferentes funções.

Os requisitos são alterados.

28

Análise e projeto de Sistemas RUP – Uso da Arquitetura de Componentes

Componentes:Grupos de código coesos, na forma de código fonte ouexecutável, com interfaces bem definidas e comportamentosque fornecem forte encapsulamento do conteúdo e são,portanto, substituíveis.

Pedaço não-trivial de software, um módulo, um pacote ou umsubsistema, sendo que todos desempenham uma função clara,possuem uma fronteira clara e podem ser integrados em umaarquitetura bem definida.

Realização de uma abstração de design.

As arquiteturas baseadas em componentes tendem areduzir o tamanho efetivo e a complexidade da solução.

29

Análise e projeto de Sistemas RUP – Modelagem Visual

Uso de notações de design gráficas e textuais paracapturar designs de software.

Uma notação, permite que o nível de abstração sejaaumentado, enquanto mantém sintaxe e semânticarígidas (UML).

Dessa maneira, a comunicação na equipe de designmelhora, à medida que o design é formado e revisado,permitindo ao leitor raciocinar sobre ele e fornecendouma base não ambígua para a implementação.

30

Análise e projeto de Sistemas RUP – Modelagem Visual

Capturar a estrutura e o comportamento.

Exibir como os elementos do sistema se integram.

Manter projeto e implementação consistentes.

Esconder ou exibir detalhes como for apropriado.

Proporcionar uma comunicação não ambígua.

31

Análise e projeto de Sistemas RUP – Contínua Verificação da Qualidade

Característica de ter demonstrado a realização da criação de um produto que atende ou excede os requisitos acordados, conforme avaliado por medidas e critérios acordados, e que é criado em um processo acordado.

Não se trata de uma única dimensão, mas de várias e para tal deve ter seus requisitos definidos.

A localização e solução de problemas ficam até 1000 vezes mais caras se realizadas após a implantação.

A verificação no decorrer do projeto é essencial.

32

Análise e projeto de Sistemas RUP – Contínua Verificação da Qualidade

Identificação das medidas e dos critérios para demonstrar a obtenção da qualidade e a implementação de um processo para garantir que o produto criado tenha atingido o grau desejado de qualidade e possa ser repetido e gerenciado.

33

Análise e projeto de Sistemas RUP – Gerenciamento de Mudança

Recurso utilizado para superar a dificuldade de controle no processo de desenvolvimento quando se fala em mudanças.

34

Análise e projeto de Sistemas RUP – Princípios Chave

Adaptar Processos.

Balancear Prioridades dos Interessados.

Colaboração entre Times.

Demonstrar Valor da Iteratividade.

Elevar o Nível de Abstração.

Foco contínuo na Qualidade.

35

Análise e projeto de Sistemas RUP – Adaptar Processo

Ciclo de vida eficiente.

Incremento da agilidade do projeto.

Uso de planos e estimativas realísticas.

36

Análise e projeto de Sistemas RUP – Balancear Prioridade dos Interessados

Alinhamento dos aplicativos às necessidades donegócio e dos usuários.

Redução do desenvolvimento customizado.

Otimização do valor do negócio.

37

Análise e projeto de Sistemas RUP – Colaboração entre Times

Incremento da produtividade do Time.

Alinhamento entre as necessidades do negócio e odesenvolvimento e operação dos Sistemas deInformação.

38

Análise e projeto de Sistemas RUP – Demonstrar Valor de Iteratividade

Redução prematura de risco.

Prognostico ao longo do projeto.

Concordância entre interessados.

39

Análise e projeto de Sistemas RUP – Elevar o nível de Abstração

Maior produtividade.

Redução dó nível de complexidade.

40

Análise e projeto de Sistemas RUP – Fóco na Qualidade

Alta qualidade.

Incremento do progresso e da qualidadeprematuramente.

41

aula 001

Documents