If718 an lise e projeto de sistemas
This presentation is the property of its rightful owner.
Sponsored Links
1 / 39

IF718 Análise e Projeto de Sistemas PowerPoint PPT Presentation


  • 73 Views
  • Uploaded on
  • Presentation posted in: General

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?

Download Presentation

IF718 Análise e Projeto de Sistemas

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


Motiva o

Motivação


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


O grande desafio

O grande desafio ...


V deo modeling through the ages

Vídeo: Modeling Through the Ages


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


    Processos de software

    Processos de software


    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 cascata

    Análise e Projeto no modelo Cascata


    An lise e projeto no modelo espiral

    Análise e Projeto no modelo Espiral


    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 projeto

    Análise versus Projeto


    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

    Estratégias de decomposiçã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


    Estrat gias de decomposi o projeto top down x bottom up

    Estratégias de decomposiçãoProjeto Top-down x Bottom-up


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

    Atributos de qualidade de modelos de análise e projeto


    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 forte

    Acoplamento Forte


    Acoplamento fraco

    Acoplamento Fraco


    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 anti padr es e frameworks

    Padrões, anti-padrões e frameworks


    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


  • Exemplo padr o fachada

    Exemplo: Padrão Fachada

    Fachada


    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


  • Login