SSC Engenharia de Software. Prof. Paulo C. Masiero

Documentos relacionados
CONCEITOS DE PROJETOS - 2. Profa. Reane Franco Goulart

CONCEITOS BÁSICOS E MODELO DE PROJETO

Princípios e Conceitos de Desenho de Software. Projeto de Sistemas de Software Prof. Rodrigo Ribeiro

Modelagem de Sistemas. Análise de Requisitos. Modelagem

Introdução à Programação. João Manuel R. S. Tavares

Profa. Reane Franco Goulart

ENGENHARIA DE SOFTWARE. Introdução

Engenharia de Software

5 Processo de Reificação e de Desenvolvimento com ACCA

Engenharia Software. Ení Berbert Camilo Contaiffer

Arquitetura de software

Introdução à Programação

Linguagens de Programação

Modelagem Orientada a Objetos

Processos de software

ENGENHARIA DE SOFTWARE

REUSO E REUSABILIDADE

Análise e Projeto de Sistemas

Engenharia de Software

Prof. Ms. Ronaldo Martins da Costa

05/09/2013. Ciclo de vida de um Sistema de Informação

Requisitos de Software

Modularização. Prof. Gustavo Willam Pereira. ENG10082 Programação II. Créditos: Prof. Clayton Vieira Fraga Filho

Princípios da Engenharia de Software aula 03

15/04/2013. Pensar Orientado a Objetos. Projeto Orientado a Objetos. Características de Objetos. Classe de Objetos. Comunicação entre Objetos

Análise e projeto de sistemas

UML 2.0 Método, Linguagem e Ferramenta. Prof. Cesar Augusto Tacla

PROJETO DE PROGRAMAS. Projeto de Programas PPR0001

Programação I Apresentação

Engenharia de Software II

Processo de desenvolvimento de sistema de informação - DSI

Engenharia de Software. Projeto de Software. Projeto: definição. Profa. Dra. Lúcia V. L. Filgueiras Profa. Dra. Selma Shin Shimizu Melnikoff

Estilos Arquiteturais. Prof. Fellipe Aleixo

Manutenção de Software

INF1404 MODELAGEM DE SISTEMAS

MODELAGEM DE SISTEMAS. Introdução a Computação e Engenharia de Software. Profa. Cynthia Pinheiro

Engenharia de Software. Projeto de Arquitetura

Análise e Projeto Orientado a Objetos

Prof. Esp. Fabiano Taguchi

ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA º PERÍODO - 7º MÓDULO AVALIAÇÃO A1 DATA 10/09/2009 ENGENHARIA DE USABILIDADE

- Engenharia Reversa - Evolução de Sofware. Desenvolvimento como. Requisitos o que. Sistema porque. Profa. Dra. Sandra Fabbri. operacional.

Engenharia de Software

Introdução à Análise e Projeto de Sistemas

PROJETO DE PROGRAMAS. Projeto de Programas PPR0001

2

Apresentação. Informação geral + Conceitos iniciais

PROJETO ARQUITETURAL PARTE II: PADRÕES DE PROJETO. Projeto de Programas PPR0001

Tópicos Avançados em Sistemas Computacionais: Infraestrutura de Hardware Aula 02

Requisitos de Software

Processos de Software

Agenda da Aula. Arquitetura de Software e Padrões Arquiteturais. Elementos de um Padrão. Arquitetura de Software. Arquitetura de Software

Resolução de Problemas com Computador. Resolução de Problemas com Computador. Resolução de Problemas com Computador

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Engenharia de Software Processo de Desenvolvimento. Ciclo de Vida - Modelo Cascata

Visões Arquiteturais. Visões Arquiteturais

Modelo do Mundo Real. Abstração. Interpretação

Como Modelar com UML 2

CONCEITOS DE LINGUAGENS DE PROGRAMAÇÃO

Professor Emiliano S. Monteiro

Bibliografia. Quais são os problemas? capacidade de construção. acompanha a demanda por novos programas. ameaçada por projetos ruins.

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA ENGENHARIA DE SOFTWARE

ARQUITETURA E DESENHO

Modelos de Processo de Software. SSC Engenharia de Software 1 Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012

6.1. Teste Baseado em Gramática e Outras Abordagens de Teste

Ferramentas CASE. CASE fornece ao engenheiro de software a habilidade de automatizar atividades manuais e de aperfeiçoar o conhecimento de engenharia.

Análise e Projeto de Software

2 Fluxos no Ciclo de Vida do Processo Unificado. O Processo Unificado consiste da repetição de uma série de ciclos durante a vida de um sistema.

Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS. Nome:

Documento de Requisitos*

Manutenção de Software. Engenharia de Software Profa. Dra. Elisa Yumi Nakagawa 1º semestre de 2016

Requisitos de sistemas

Projeto de Banco de Dados. Componentes de um Sistema de Informação. Arquitetura de SI. Sistema de Informação (SI) SI nas Organizações

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Sintática: como é escrito cada elemento da linguagem de programação.

3 Uma Abordagem Orientada a Aspectos para o Desenvolvimento de Frameworks

Título PROCESSO LABES ESPECIALIZADO PARA DESENVOLVIMENTO SEGUNDO O PARADIGMA ESTRUTURADO. Projeto. Analista; Requisitos Funcionais Escopo; Cliente;

Lista de Exercícios AV1

DIAGRAMAS DE CLASSE UML

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

Universidade Federal da Paraíba CCEN Departamento de Informática Disciplina: Banco de Dados. Aula 1 Introdução a Banco de Dados

Atividades de Desenvolvimento. Desenvolvimento de Software. Especificação de Requisitos. Atividades de Desenvolvimento. Especificação de Requisitos

Teste de Software. Competência: Entender as técnicas e estratégias de testes de Software

INF014 Análise e Projeto de Sistemas Ciclos de vida e Processos de Software

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Capítulo 2. Orientação a Objetos

Análise de sistemas. Engenharia de Requisitos

Padrões. Arquitetura de Software Thaís Batista

Organização para Realização de Teste de Software

Introdução. Parte 01. Desenvolvimento de Programação Orientada a Objetos. Prof. Pedro Neto

3ª Aula. Processo de Projeto em SE Exemplo de projeto: Sistema de Mapa GPS. Introdução. PSI3441 Arquitetura de Sistemas Embarcados

Desenvolvimento de Software Baseado em Componentes. Paulo C. Masiero

Qualidade de Software QUALIDADE DE SOFTWARE PRODUTO

S15 - Engenharia de Requisitos continuação cap.6

Manutenção de Software. Engenharia de Software Profa. Dra. Elisa Yumi Nakagawa 1º semestre de 2015

Paradigmas da Engenharia de Software AULA PROF. ABRAHAO LOPES

Transcrição:

SSC - 5764 Engenharia de Software Prof. Paulo C. Masiero

Processo de Software: Fases ou Subprocessos DEFINIÇÃO CONSTRUÇÃO MANUTENÇÃO Análise de Sistema Análise de Requisitos Projeto Projeto Processo pelo qual os requisitos do software são traduzidos para uma representação do software que permite sua realização física. 2

Modelo de Informação Modelo Funcional Outros Requisitos Modelo Comportamental Projeto Projeto de Interface Projeto Arquitetural Projeto de Dados Codificação Projeto Procedimental Programas Teste Software Integrado e Validado 3

Ponto de Vista Técnico DADOS: o modelo de domínio da informação é transformado nas estruturas de dados que serão exigidas para implementar o software. ARQUITETURAL: o relacionamento entre os grandes componentes estruturais do programa é definido. INTERFACE: os mecanismos de interação e layout para a interação homem-máquina são estabelecidos. PROCEDIMENTAL: os componentes estruturais são transformados em uma descrição procedimental do software. 4

Ponto de Vista Gerencial PROJETO PRELIMINAR: preocupa-se com a transformação dos requisitos do software em uma arquitetura de software e de dados. PROJETO DETALHADO: concentra-se nos aprimoramentos da representação arquitetural que levam à estrutura de dados detalhada e às representações algorítmicas do software. 5

Projeto preliminar Projeto detalhado Projeto procedimental Projeto de interface Projeto arquitetural Projeto de dados 6

Fomentar a qualidade durante o processo de desenvolvimento. Fornecer representações do software que podem ser avaliadas quanto à qualidade. Traduzir com precisão os requisitos de um cliente num produto de software finalizado. 7

Sistema instável. Falhará Manutenção quando pequenas mudanças forem feitas. Difícil de testar. Qualidade não pode ser verificada Teste até um ponto tardio do processo de desenvolvimento. Implementação Projeto COM projeto Manutenção Teste Implementação SEM projeto 8

Modelo de Informação Modelo Funcional Outros Requisitos Modelo Comportamental Projeto Projeto de Dados Projeto Procedimental Projeto de Interface Projeto Arquitetural Codificação Projeto de Dados Objetivo Selecionar representações lógicas dos dados (estruturas de dados), identificados Programas durante a fase de especificação Software dos Teste requisitos. Integrado e Validado 9

ESTRUTURA DE DADOS: é uma representação do relacionamento lógico entre elementos de dados individuais. Determina a organização, métodos de acesso, grau de associatividade e alternativas de processamento de informações. 10

Você moraria em uma casa em que não há um projeto (planta)? 11

Modelo de Informação Modelo Funcional Outros Requisitos Modelo Comportamental Projeto Projeto de Dados Projeto Procedimental Projeto de Interface Projeto Arquitetural Codificação Programas Projeto Arquitetural Objetivo Desenvolver uma estrutura modular do sistema e representar as relações de controle entre os módulos. Teste Software Integrado e Validado 12

O projeto arquitetural une a estrutura de programa e a estrutura de dados, definindo interfaces que possibilitam que os dados fluam pelo programa. 13

Propriedades que devem ser especificadas como parte de um projeto arquitetural: Propriedades estruturais: este aspecto da representação do projeto arquitetural define os componentes do sistema (como módulos, objetos) e a maneira pela qual esses componentes são empacotados e interagem entre si. 14

Propriedades que devem ser especificadas como parte de um projeto arquitetural: Propriedades extra-funcionais: a descrição do projeto arquitetural deve cuidar de como a arquitetura do projeto alcança os requisitos de desempenho, capacidade, confiabilidade, segurança, adaptabilidade, e outros requisitos não funcionais do sistema. 15

Propriedades que devem ser especificadas como parte de um projeto arquitetural: Famílias de sistemas relacionados: o projeto arquitetural deve ter a capacidade de reusar blocos de construção arquitetural. 16

O projeto arquitetural pode ser representado usando-se um ou mais modelos: Modelo estrutural: representa a arquitetura como uma coleção organizada de componentes de programa. Modelo de arcabouço (framework): aumenta o nível de abstração de projeto por meio de tentativas de identificar padrões de projeto arquitetural repetidos, encontrados em tipos de aplicações similares. 17

O projeto arquitetural pode ser representado usando-se um ou mais modelos: Modelo dinâmico: cuida dos aspectos comportamentais da arquitetura do programa, indicando como a estrutura ou configuração do sistema pode mudar em reação a eventos externos. Modelo de processo: focaliza o projeto de negócios ou processo técnico que o sistema precisa atender. 18

O projeto arquitetural pode ser representado usando-se um ou mais modelos: Modelo funcional: pode ser usado para representar a hierarquia funcional do sistema. 19

Abstração Refinamento Modularidade CONCEITOS Ocultação da Informação Independência Funcional Arquitetura Particionamento Estrutural 20

ABSTRAÇÃO: possibilita que o projetista represente os procedimentos, os dados e o controle em vários níveis de detalhes. Uma solução: é declarada em termos amplos usando-se a linguagem do ambiente do problema é estabelecida usando-se uma terminologia orientada à implementação é estabelecida de uma forma que possa ser diretamente implementada alto Nível de Abstração baixo 21

Abstração Procedimental: uma sequência de instruções designadas que têm uma função específica e limitada. Ex: a palavra entrar numa porta Sequência de passos procedimentais: caminhe até a porta, aproxime-se e segure a maçaneta, gire a maçaneta e empurre a porta, etc... 22

Abstração de Dados: uma coleção designada de dados que descrevem um objeto de dados. Ex: cheque de pagamento Trata-se de uma coleção de muitas informações diferentes: nome da pessoa a quem se paga, quantia bruta paga, imposto retido, contribuição para a previdência, etc. 23

Abstração de Controle: implica um mecanismo de controle do programa sem especificar detalhes internos. Ex: semáforo de sincronização Utilizado para coordenar atividades de um sistema operacional. 24

REFINAMENTO passo a passo: é uma antiga estratégia de projeto top-down (1971) A arquitetura de um programa é desenvolvida refinando-se, sucessivamente, os níveis de detalhes procedimentais. 25

MODULARIDADE: o software é dividido em componentes (módulos), que são integrados para atender aos requisitos do problema. Dividir para conquistar. Um projeto modular reduz a complexidade, facilita a mudança e resulta numa implementação mais fácil ao estimular o desenvolvimento paralelo de diversas partes de um sistema. 26

MODULARIDADE É mais fácil resolver um problema complexo quando ele é dividido em partes. Dividir indefinidamente torna o problema infinitamente pequeno? NÃO A submodularidade ou a supermodularidade devem ser evitadas. COMO DEFINIR UM TAMANHO DE MÓDULO APROPRIADO? 27

28

OCULTAÇÃO DE INFORMAÇÕES: o conceito de modularidade leva o projetista de software a uma questão fundamental: Como decompor uma solução de software para obter o melhor conjunto de módulos? O princípio da "ocultação de informações" sugere que os módulos sejam "caracterizados pelas decisões de projeto que (cada módulo) esconde de todos os outros". 29

Os módulos devem ser especificados e projetados de tal forma que as informações (procedimentos e dados) contidas num módulo sejam inacessíveis a outros módulos que não tenham necessidade de tais informações. A ocultação implica em uma modularidade tal que um conjunto de módulos independentes comunicam entre si somente aquelas informações que são necessárias para se obter a função do software. 30

INDEPENDÊNCIA FUNCIONAL: produto direto da modularidade e do conceito de ocultação da informação. Alcançada desenvolvendo-se módulos com função "com um só propósito" e "aversão" a interações excessivas com outros módulos; Um software com módulos independentes é mais fácil de ser desenvolvido e mais fácil de ser mantido => fundamental para um bom projeto. 31

A INDEPENDÊNCIA FUNCIONAL é medida usando-se dois critérios qualitativos: COESÃO ACOPLAMENTO 32

A INDEPENDÊNCIA FUNCIONAL é medida usando-se dois critérios qualitativos: COESÃO ACOPLAMENTO COESÃO Medida da força funcional relativa de um módulo. Pode ser vista como a força que mantém unidos os elementos de um módulo. 33

A INDEPENDÊNCIA FUNCIONAL é medida usando-se dois critérios qualitativos: COESÃO ACOPLAMENTO É o grau de interdependência entre os módulos. ACOPLAMENTO 34

PARTICIONAMENTO ESTRUTURAL: a estrutura do programa deve ser particionada horizontalmente e verticalmente particionamento horizontal: define três partições: entrada, transformação de dados (processamento) e saída. Função 1 Função 3 Função 2 35

PARTICIONAMENTO ESTRUTURAL: a estrutura do programa deve ser particionada horizontalmente e verticalmente particionamento vertical: módulos de nível mais alto devem realizar funções de controle; os módulos de nível mais baixo devem realizar as tarefas de entrada, processamento e saída. Módulos de tomada de decisão Módulos `trabalhadores Função 1 Função 3 Função 2 36

ARQUITETURA DE SOFTWARE é a estrutura hierárquica de componentes de programa (módulos), o modo pelo qual estes componentes interagem e as estruturas de dados que são usadas pelos componentes. 37

Projeto Arquitetural: ARQUITETURA DO SOFTWARE Princípios básicos de projeto para arquiteturas modulares: (1) unidades modulares; (2) poucas interfaces; (3) interfaces pequenas (fraco acoplamento); (4) interfaces explícitas; (5) ocultação de informações. 38

Projeto Arquitetural: ARQUITETURA DO SOFTWARE Princípios básicos de projeto para arquiteturas Correspondem aos módulos do sistema. modulares: (1) unidades modulares; (2) poucas interfaces; (3) interfaces pequenas (fraco acoplamento); (4) interfaces explícitas; (5) ocultação de informações. 39

Projeto Arquitetural: ARQUITETURA DO SOFTWARE Princípios básicos de projeto para arquiteturas modulares: (1) unidades modulares; (2) poucas interfaces; (3) interfaces pequenas (fraco acoplamento); (4) interfaces explícitas; Para conseguir baixo acoplamento: o número de interfaces entre os módulos e a quantidade de informações que se movimentam por uma interface devem ser minimizados. (5) ocultação de informações. 40

Projeto Arquitetural: ARQUITETURA DO SOFTWARE Princípios básicos de projeto para arquiteturas modulares: (1) unidades modulares; (2) poucas interfaces; Quando os módulos precisam se comunicar, eles devem fazê-lo de uma maneira óbvia e direta. (3) interfaces pequenas (fraco acoplamento); (4) interfaces explícitas; (5) ocultação de informações. 41

Projeto Arquitetural: ARQUITETURA DO SOFTWARE Princípios básicos de projeto para arquiteturas modulares: (1) unidades modulares; (2) poucas interfaces; Todas as informações sobre um módulo são escondidas do acesso externo. (3) interfaces pequenas (fraco acoplamento); (4) interfaces explícitas; (5) ocultação de informações. 42

Modelo de Informação Modelo Funcional Outros Requisitos Modelo Comportamental Projeto Projeto de Interface Projeto de Dados Projeto Arquitetural Projeto Procedimental Codificação Projeto Procedimental Objetivo Especificar os detalhes dos algoritmos de forma não ambígua. Programas Teste Software Integrado e Validado 43

PROCEDIMENTO DE SOFTWARE: focaliza os detalhes de processamento de cada módulo individualmente. O Procedimento deve oferecer uma especificação precisa do processamento (sequência de eventos, pontos de decisão, operações repetitivas e até mesmo estrutura e organização de dados). 44

Linguagem de projeto de programa (inglês estruturado ou pseudocódigo) É uma linguagem híbrida no sentido de que ela usa o vocabulário de uma linguagem (isto é, inglês) e a sintaxe global de outra (isto é, uma linguagem de programação estruturada). 45

Características: 1- uma sintaxe fixa de palavras-chave que forneçam todas as construções estruturadas, declarações de dados e características de modularidade. 2- uma sintaxe livre de linguagem natural que descreva as características de processamento. 3- facilidades de declaração de dados que incluam tanto as estruturas de dados simples como as complexas. 4- a definição de subprogramas ou técnicas de chamada que apóiem vários modos de descrição de interfaces. 46

Nas fases iniciais, costuma-se usar declarações que informam Pré-condições Pós-condições É uma linguagem baseada em lógica matemática Usado por exemplo em casos de uso e contratos. 47

Modelo de Informação Modelo Funcional Outros Requisitos Modelo Comportamental Projeto Projeto de Dados Projeto Procedimental Projeto de Interface Projeto Arquitetural Codificação Programas Projeto de Interface Objetivo Estabelecer os mecanismos de interação e layout para a interação homemmáquina Teste Software Integrado e Validado 48

Processo iterativo, abrangendo as atividades: Análise e modelagem do usuário, tarefa, ambiente. Projeto da interface. Tempo de resposta do sistema. Facilidades de ajuda ao usuário. Manipulação de informações de erro. Rotulação de comandos. 49

Construção da interface. Ferramentas de projeto de interface e prototipagem. Fornecem componentes de software préempacotados para criar uma interface com o usuário. Validação da interface. Determinar se o protótipo operacional da interface satisfaz as necessidades do usuário. Dados qualitativos. Dados quantitativos. Experimentos de usabilidade Acessibilidade 50

Regras de Ouro. Coloque o usuário no controle. Reduza a sobrecarga cognitiva do usuário. Faça a interface consistente.... 51

Modelo de Informação Modelo Funcional Outros Requisitos Modelo Comportamental Projeto Projeto de Interface Projeto Arquitetural Projeto de Dados Codificação Projeto Procedimental Programas Teste Software Integrado e Validado 52

SSC - 5764 Engenharia de Software Profa. Ellen Francine