Você está na página 1de 28

Projeto de Software

SWEBOK
Projeto de Software

1. Fundamentos
2. Questões básicas
3. Arquitetura de software
4. Análise e avaliação de qualidade
5. Notações
6. Estratégias e métodos
Fundamentos (1)

 Conceitos, noções e terminologia que


formam a base para compreender o papel e
o escopo do projeto de software.
a) Conceitos
b) Contexto do projeto de software
c) Processo do projeto de software
d) Princípios do projeto de software
SWEBOK
Conceitos (1a)
Projeto de software

 [IEEE 610.12-90]
 “o processo de definir a arquitetura, os
componentes, as interfaces e outras
características de um sistema ou
componente”,
e
 “o resultado de tal processo”.
Conceitos (1a)

 Visões
 Projeto de software como um problema maligno
(“wicked”)
 Compreensão dos limites da atividade de “design” e de
projeto de software
 Projeto como processo desordenado
 Projeto de software como um processo heurístico
 Projeto de software: ciência, engenharia ou arte?
O contexto do projeto de software (1b)

 Projeto de software inclui atividades que se


encaixam entre:
 análise de requisitos de software e
 construção de software
An. de Requisitos

 e interage com:
Projeto de software
 teste de software

Construção
SWEBOK
O processo de projeto de software (1c)

 Atividade que transforma uma descrição


sobre o quê se quer resolver (usando termos
relevantes ao domínio do problema)
em uma descrição que explica como resolver
o problema

O quê Como

documento de requisitos modelos e artefatos


de projeto
SWEBOK
Projeto de software
Perspectiva de processo
 Atividades principais
 Projeto arquitetural (“top-level design”)
 Projeto detalhado

 Entrada
 documento(s) de especificação de requisitos

 Resultados
 um conjunto de modelos e artefatos de projeto que
documentam as principais decisões tomadas.
Projeto de software
Perspectiva de resultado
 Projeto de arquitetura
 descrição de como o sistema é decomposto e organizado
em componentes, das interfaces entre esses
componentes, dos relacionamentos entre componentes

 Projeto detalhado
 descrição detalhada dos componentes até um nível de
detalhamento que permita a sua construção.

 Resultados
 um conjunto de modelos e artefatos de projeto que
documentam as principais decisões tomadas
RUP: Alguns artefatos de projeto
Projeto de Software

 Artefatos de projeto
 podem ser analisados e avaliados para se verificar
se atendem aos requisitos
 podem ser examinados na busca por diversas
soluções alternativas e avaliação de trade-offs
 podem ser usados para planejar atividades de
desenvolvimento subsequentes
 são usados como entrada e ponto inicial para as
atividades de construção e testes
Princípios do projeto de software (1d)

 Princípios considerados fundamentais para


diversas abordagens de projeto de software
 abstração
 decomposição e modularidade
 acoplamento e coesão
 ocultamento de informação e encapsulamento
 separação entre interface e implementação
Questões básicas do projeto de software (2)

 Questões que a maior parte das abordagens de


projeto de software precisam se preocupar

 Critérios para decompor, organizar, e “empacotar” software


 Atributos de qualidade (ex. desempenho, usabilidade)
 Outros aspectos
 Concorrência
 Tratamento de erros
 Distribuição de componentes
 Interação e apresentação
 Persistência de dados
 ...
Arquitetura de software (3)

A software architecture for a system is the


structure or structures of the system, which
consists of elements, their externally visible
properties, and the relationships among
them.
(Bass, Clements, Kazman 1998)

 Outras definições
Projeto estratégico x tático

 Projeto arquitetural (estratégico)


 global design constraints, such as programming
paradigms, architectural styles, component-based
software engineering standards, design principles.
 Projeto detalhado (tático)
 local design constraints, such as design patterns,
programming idioms, and refactorings.
Arquitetura de software
Tópicos relacionados
 visões e estilos arquiteturais
 padrões de projeto
 micro-arquiteturas
 frameworks, famílias de produtos
Análise e avaliação de qualidade (4)

 Vários atributos são considerados


importantes para se obter um projeto de
software de boa qualidade
 vários “ilities”
 maintainability, portability, testability, traceability, etc.
 vários “nesses”
 correctness, robustness, fitness of purpose
Atributos de Qualidade

 Atributos de qualidade externos


 performance, security, availability, functionality,
usability

 Atributos de qualidade internos


 modifiability, portability, reusability, integrability
and testability
Técnicas para análise e avaliação de
qualidade
 Várias ferramentas e técnicas podem ajudar
a assegurar a qualidade de um projeto de
software

 Revisões de projeto
 Análises estáticas
 Simulação
 Prototipagem
Medições
 Medições podem ser utilizadas para investigar ou
estimar quantitativamente vários aspectos do
projeto de software
 tamanho, estrutura, etc.

 Medições em geral dependem da


abordagem/estratégia usada durante a atividade de
projeto:
 métricas de projeto orientado a objetos
SWEBOK
Projeto de software
Notações (5)
 Descrição estrutural  Descrição
 caixas e setas comportamental
 architecture descr. languages  diagramas de sequência
(ADLs)  diagramas de colaboração
 collaboration responsibilities  diagramas de estado
cards (CRCs)
 etc.
 diagramas de classe
 DER
 etc.
Diagrama de objeto e diagrama de classe
Diagrama de sequência

Diagrama de colaboração
Estratégias e métodos (6)

 There exist various general strategies to help guide


the design process
 divide-and-conquer
 stepwise refinement
 top-downn, bottom-up
 abstraction, information hiding
 use patterns
Estratégias e métodos (6)

 Métodos são mais específicos e provêm:


 a set of notations to be used with the method,
 a description of the process to be used when following the
method and
 a set of guidelines in using the method

 Projeto funcional (estruturado)


 Projeto orientado a objetos
 Projeto baseado em componentes
 Métodos formais
Referências

 SWEBOK