If718 an lise e projeto de sistemas
Download
1 / 39

- 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 '' - 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: realidadecontrole 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 realidade

  • 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



V deo modeling through the ages
Vídeo: realidadeModeling Through the Ages


Objetivos do curso
Objetivos do curso realidade

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

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

    • 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 cascata
    Análise e Projeto realidadeno modelo Cascata


    An lise e projeto no modelo espiral
    Análise e Projeto realidadeno modelo Espiral


    An lise e projeto no modelo iterativo do rup
    Análise e Projeto realidade 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 realidade(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 realidade

    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 realidade

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

    • 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ção realidadeFuncional 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ção realidadeFuncional 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


    Estrat gias de decomposi o projeto top down x bottom up
    Estratégias de decomposição realidadeProjeto Top-down x Bottom-up


    Projeto top down x bottom up
    Projeto Top-down x Bottom-up realidade

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

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

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

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

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

    • 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


  • Exemplo padr o fachada
    Exemplo: Padrão Fachada realidade

    Fachada


    Anti padr es
    Anti-Padrões realidade

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

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

    • Programa, cronograma, transparências, referências, avaliação, projetos e ferramentas:

      • http://www.cin.ufpe.br/~if718

    • MAS SÓ DEPOIS DA QUINTA-FEIRA