if718 an lise e projeto de sistemas
Download
Skip this Video
Download Presentation
IF718 Análise e Projeto de Sistemas

Loading in 2 Seconds...

play fullscreen
1 / 39

IF718 Análise e Projeto de Sistemas - PowerPoint PPT Presentation


  • 94 Views
  • Uploaded on

IF718 Análise e Projeto de Sistemas. Augusto Sampaio - acas Pedro Antonino – prga2 (Estágio docência) 2013.2. Parte do material cedido pela Qualiti Software Processes. Motivação. Essência de Análise e Projeto: construção de modelos. O que é um modelo? Por que construir modelos?

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 ' IF718 Análise e Projeto de Sistemas' - kamin


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
if718 an lise e projeto de sistemas

IF718Análise e Projeto de Sistemas

Augusto Sampaio - acas

Pedro Antonino – prga2 (Estágio docência)

2013.2

  • Parte do material cedido pela Qualiti Software Processes
ess ncia de an lise e projeto constru o de modelos
Essência de Análise e Projeto: construção de modelos
  • O que é um modelo?
  • Por que construir modelos?
  • Quantos modelos construir para:
    • capturar os elementos do problema
    • Representar diferentes níveis de abstração
  • Em Engenharia de Software
    • O que é Desenvolvimento Baseado em Modelos?
um modelo uma vis o parcial representa o da realidade
Um modelo é uma visão parcial (representação) da realidade

Modelos

(visões parciais)

Representa

Realidade

Sistema respiratório

  • Outros modelos:
  • Muscular,
  • Nervoso,
  • Circulatório,
  • Digestivo,
  • etc.

Esqueleto

multiplas vis es controle da complexidade
Multiplas visões: controle da complexidade

System

Model

repOf

Plumber\'s

view

Architect\'s

view

Landlord\'s

view

Renter\'s

view

Mason\'s

view

Interior

Designer\'s

view

Carpenter\'s

view

Tax

Collector\'s

view

Electrician\'s

view

desenvolvimento baseado em modelos
Desenvolvimento baseado em modelos
  • A principal motivação é aumentar a produtividade:
    • Independência de tecnologia
    • Reutilização
    • Automação
  • Aumentar o nível de abstração
    • Foco no modelo, não no código
    • “O modelo é o código ...”
  • Processos são essenciais para sistematizar o desenvolvimento
objetivos do curso
Objetivos do curso
    • Processo de Análise e Projeto no RUP
  • Aspectos de modelagem de paradigmasrecentes:
    • SOA (Software-Oriented Architecture)
    • MDD (Model-Driven Development)
  • Técnicas de modelagem OO em UML
  • Ênfase em Padrões de Projeto e Arquiteturais
  • Consolidação dos conceitos em um exemplo construído incrementalmente
  • Uso de ferramentas de modelagem
  • Geração de esqueleto de código
conte do do curso
Conteúdo do curso
  • Análise/projeto no RUP
    • Disciplina de A&P
    • Análise de caso de uso
    • Projetararquitetura
    • Projetarcasos de uso
  • Considerando SOA e MDD
    • Modelo de negócio
    • Analisar serviços
    • Projetar serviços
  • Padrões de projeto e arquiteturais
  • Projetar subsistemas (componentes)
  • Projetar classes
  • Projetar concorrrência e distribuição
  • Projetar base de dados

Aulas conceituais e prática em laboratório

Exemplo único para ilustrar conceitos

processo de software
Processo de software
  • Para ser uma atividade sistematizada, Análise e Projeto deve ser parte de um processo
  • Processo:
    • O que é?
    • Representação?
    • Ciclo de vida?
    • Execução?
    • Modelos de processo
an lise e projeto no modelo iterativo do rup
Análise e Projeto no modelo iterativo do RUP

Fases

Fluxos de Processo

Transição

Concepção

Elaboração

Construção

Requisitos...............................

Análise e Projeto......................

Implementação........................

Testes...................................

Implantação............................

Fluxos de Suporte

Gerência de Configuração............

Planejamento e Gerenciamento.....

Inicial

Iterações

an lise e projeto em soa service oriented architecture
Análise e Projeto em SOA(Service Oriented Architecture)

Requisitos

Especificação do

modelo de negócios

Modelagem do

Negócio

Analisar serviços

Planejamento

Projetar Serviços

Planejamento

Inicial

Implementação

Avaliação

Teste

an lise versus projeto1
Análise versus Projeto

Análise

Foco no problema

Comportamento (caixa preta, sem detalhes de implementação)

Estrutura geral da arquitetura do sistema

Requisitos funcionais

Modelo simples

Projeto

Foco em uma solução

Operações e atributos

Representação próxima do código

Requisitos não-funcionais (exemplo: desempenho), além dos funcionais

Modelo complexo

Fonte: Rational

an lise versus projeto2
Análise versus Projeto
  • Em MDD (Model Driven Development) da OMG (Object Management Group) ...
    • Análise corresponde aos modelos independentes de plataforma (PIM – Platform Independent Model)
    • No projeto, os modelos podem estar vinculados a uma tecnologia particular (PSM – Platform Specific Model)
modelo de an lise e projeto
Modelo de Análise e Projeto
  • Pode ser um só artefato
    • evoluindo de uma visão abstrata (nas atividades de análise), para uma visão detalhada (nas atividades de projeto)
  • Podem ser feitos dois artefatos
    • um modelo de análise
    • um modelo de projeto (inicia igual à última versão do modelo de análise e evolui independentemente)
  • Documentação x esforço e disciplina de manutenção
estrat gias de decomposi o funcional x dados
Estratégias de DecomposiçãoFuncional x Dados
  • Decomposição Funcional
    • Decomposição do sistema em componentes funcionais (exemplo: casos de uso)
    • O estado do sistema é centralizado e compartilhado entre as funções
    • Experiência mostrou inadequação para estruturação de modelos de análise e projeto (as regras de negócio mudam constantemente)
    • Entretanto, útil para estruturar requisitos, planejar e gerenciar projetos, e realizar testes
estrat gias de decomposi o funcional x dados1
Estratégias de DecomposiçãoFuncional x Dados
  • Decomposição Baseada em Dados
    • O sistema é visto como uma coleção de entidades que interagem (ou objetos, no paradigma OO)
    • O estado do sistema é descentralizado
    • Mostrou-se adequada como mecanismo de estruturação (estabilidade de dados com relação a funções) de
      • modelos de análise
      • projeto e
      • implementação
projeto top down x bottom up
Projeto Top-down x Bottom-up
  • Na prática, o projeto de grandes sistemas nunca é inteiramente top-down
    • Os projetistas reutilizam experiência (e componentes)
    • No processo, ocorre brainstorm nos dois sentidos
atributos de qualidade
Atributos de Qualidade
  • A qualidade é uma propriedade relativa a prioridades específicas da organização
  • Características de qualidade são igualmente aplicáveis a projetos orientados a objeto ou à função
  • Dois atributos importantes são coesão e acoplamento
o atributo coes o
O Atributo Coesão
  • Medida da proximidade das partes (elementos) de um componente do sistema
  • Um componente deve implementar uma única entidade lógica ou função (abstração)
  • Importância
    • Quando uma mudança tiver que ser feita, ela será facilmente localizada
    • Reuso ...
  • Em Orientação a objetos, cada classe deve modelar uma única entidade
o atributo acoplamento
O Atributo Acoplamento
  • Medida da intensidade das interconexões entre componentes do sistema
  • Importância
    • Baixo acoplamento implica que mudanças em um componente tendem a não afetar outros componentes
    • Reuso ...
acoplamento em orienta o a objetos
Acoplamento em Orientação a Objetos
  • Sistemas orientados a objeto são, potencialmente, fracamente acoplados
    • Geralmente não compartilham estado
    • A comunicação é feita através de passagem de mensagens
  • Entretanto...
    • uma classe está acoplada a sua superclasse (mudanças nos atributos ou operações se propagam a todas as subclasses)
    • Relacionamentos cíclicos (em particular, bidirecionais) também geram forte acoplamento
padr es de projeto e arquiteturais
Padrões de Projeto e Arquiteturais
  • Projetistas experientes (re)utilizam soluções bem sucedidas no passado
  • Padrões sistematizam soluções, incluindo
      • Nome
      • Problema
      • Solução
      • Conseqüência
      • Exemplo, ...
  • Durante as duas última décadas, surgiu uma “comunidade” voltada a padrões
anti padr es
Anti-Padrões
  • São uma maneira de documentar soluções recorrentes que não tiveram sucesso
      • Podem também incluir soluções re-trabalhadas que sejam efetivas
frameworks
Frameworks
  • Usualmente baseado em padrões, mas já voltados para uma linguagem de programação
  • Especialização/instanciação
    • Hot spots
    • Herança
relacionamento com outras disciplinas do processo de software
Relacionamento com outras disciplinas do processo de software
  • Planejamento e Gerenciamento – planeja e acompanha todo o desenvolvimento
  • Requisitos – entrada para a análise e projeto do sistema
  • Implementação – o modelo de análise e projeto é entrada a implementação
  • Gerência de Configuração e Ambiente – oferece suporte aos artefatos gerados (incluindo modelos)
planejamento do curso
Planejamento do Curso
  • Programa, cronograma, transparências, referências, avaliação, projetos e ferramentas:
    • http://www.cin.ufpe.br/~if718
  • MAS SÓ DEPOIS DA QUINTA-FEIRA
ad