Software de Prateleira (Comercial off the shelf) -> pronto, o cliente se adapa ao sistema

Software sob encomenda -> software desenvolvido de acordo com as necessidades do cliente

erro de projeto -> faz o que o cliente pediu

erro de cdigo -> executa erradamente o que o cliente pediu

modelo -> representao idealizada de um sistema que se planeja construir

Diagramas e documentaes so os principais tipos de modelos de software... A documentao do

modelo o seu diagrama junto com a informao textual associada.

A modelagem de sistemas de software consiste na utilizao de notaes grcas e textuais com o

objetivo de construir modelos que representam as partes essenciais de um sistema, considerando-se
diversas perspectivas diferentes e complementares

eng de softwares fazem modelos

A UML a linguagem padro para visualizar, especicar, construir e documentar os artefatos de

software de um sistema Elementos grcos que representam os conceitos de orientao a objeto
Sintaxe: Forma pr-denida de desenhar o elemento grco Semntica: Signicado pr-determinado e
para que serve

UML

UML independente de linguagem de programao e processo de desenvolvimento UML uma

linguagem visual, no uma linguagem de programao UML no um tcnica de modelagem

UML independente de linguagem de programao e processo de desenvolvimento UML uma

linguagem visual, no uma linguagem de programao UML no um tcnica de modelagem

Viso de caso de uso -> a primeira viso a ser criada Ponto de vista externo (viso geral) InViso de
Projeto

Caractersticas do sistema -> Funcionalidades visveis externamenteteraes entre o sistema e os

agentes externos

Viso de Implementao -> Gerenciamento de verses do sistema Agrupamento de componentes

(mdulos) de sub-sistemas

Viso de Implantao -> Distribuio fsica do sistema e seus mdulos Conexo fsica ou lgica entre as
partes do sistema

Artefatos de software -> documentos gerados durante a modelagem

--------------------------------------------------------------

PDS -> Compreende todas as atividades necessrias para denir, desenvolver, testar e manter um
sistema de software Um processo descreve quem (papel) est fazendo o qu (artefato), como
(atividades) e quando (disciplina).

existem vrios: RUP, XP, ICONNIX, UP, Scrum, PAS

divide-se em 5 fases: levantamento de requisitos, anlise, projeto, implementao, testes,

implementao

levantamento de requisitos -> cliente e desenvolvedor tm a mesma viso do problema; definio dos
requisitos (necessidades dos usurios do sitema). Essa fase resulta num documentos de requisitos.
requisito funcional -> Denem as funcionalidades reais do sistema. Comportamento esperado. O que o
sistema faz.

Requisito No-Funcional -> Caractersticas de qualidade. Restries. Como o sistema deve operar.
Conabilidade Desempenho Portabilidade Segurana

Essa fase deve responder o que usurios precisa do sistema; foca somente no problema; estabelece o
escopo do sitema, ordenados em grau de prioridade;

Pensar na soluo sem se preocupar em como ser desenvolvido Primeiro deni-se o que o sistema
deve fazer para depois denir como esse sistema ir fazer.

Os modelos construdos na anlise devem ser validados e vericados O software correto ir ser
desenvolvido ? O software est sendo desenvolvido corretamente ?

anlise de projeto -> Na fase de projeto determina-se como o sistema ir funcionar Considera os
aspectos fsicos e dependentes de implementao So adicionados aos modelos as restries
tecnolgicas Arquitetura do sistema Gerenciador de Banco de Dados Linguagens de programao

Projeto da arquitetura (projeto de alto nvel) Arquiteto de software Dividir classes e objetos em
modulos Diagramas de Implementao. Projeto detalhado (projeto de baixo nvel) Como as classes e
objetos colaboram entre si Projeto de interface grca junto ao cliente Modelagem do banco de
dados (DER) Diagramas de interao e estados

Implementao do sistema -> Codicao do sistema na linguagem especicada na fase de projeto.

Traduo dos modelos obtidos nas fases anteriores em cdigo de maquina. Utilizao de frameworks
para produtividade.

Testes -> Testes de unidade Suite de testes Testes de caixa preta Especicao de testes.

Implantao -> Sistema empacotado, distribuido e instalado Documentao de uso escrita

Treinamento dos usurios Migrao de sistemas antigos

---------------------------------------------------------------

Participantes do Processo

Gerentes Analistas Projetistas Programadores Clientes Qualidades

gerente -> coordena as atividades necessrias para construo do sitema; estima custos e
cronogramas...

analista -> responsvel pelo levantamento de requisitos, ponte de comunicao entre cliente e
programadores. A organizao muita das vezes contrata o analista no seu quadro ao nal do projeto
Sabe sobre partes condenciais da organizao.projetistas -> Responsveis pela fase de projeto
Avaliar alternativas de solues para o problema levantado Escolher e gerar soluo detalhada
Projetistas de rede Projetistas de interface Projetistas de Banco de Dados

arquiteto de software -> Trabalha em conjunto com projetistas e gerentes Elaborao da arquitetura
geral do sistema Quais mdulos devem existir Interface de comunicao entre mdulos Decises
tcnicas no dia-a-dia

programador -> principal ator da fase de implementao; deve saber ler os modelos resultantes das
fases anteriores; traduz esses modelos em mdulos de sistemas...

clinte -> quem est contratando o sistema a ser construdo. Cliente usurio: quem vai de fato utilizar o
sitema; Cliente contratante: quem paga pelo sistema que o cliente ir utilizar
testador -> Certica a qualidade dos modulos de software a serem entregues aos clientes Seguem
especicaes de testes e acham bugs para os programadores corrigirem Verica se o sistema
construdo reete os modelos executados nas fases iniciais

---------------------------------------------------------------

Modelos do ciclo de vida -> como acontecem as conexs das fases de um PDS. Existem vrios modelos,
a diferena est na maneira que as fases so encadeadas: modelo cascata, modelo iterativo, modelo
gil.

cascata -> PDS reais no seguem um sequenciamento entre as fases Geralmente so realizadas em
paralelo Levantar todos os requisitos antes do inicio das prximas fases Erros no levantamento
levam a erros nas demais fases No tem uma verso intermediria funcional

iterativo -> Dividido em vrios pequenos ciclos Cada ciclo composto pelas fases de PDS Como se
cada ciclo fosse uma mini-cascata" Cada ciclo considera um subconjunto de requisitos a ser
desenvolvido Chamado de incremento de software. Cada incremento tras extenses e renamentos
ao incremento anterior Cada incremento denido como uma verso funcional do software sendo
construdo Diferente do cascata que tinha uma verso funcional apenas no nal. Os riscos de projeto
so revisitados baseados em cada ciclo Podem ocorrer pequenas alteraes em custos, equipe,
cronograma, qualidade, entre outros. Os primeiros requisitos so aqueles que tem o maior risco
Erros no levantamento rapidamente corrigido no prximo ciclo. Vantagens: Lidando com mudanas
contnuas nos requisitos Maior exibilidade para mudana nos planos Integrao Continua
Entendimento Precoce do sistema Foco nos riscos. Desvantagens: Gerenciamento ca mais difcil em
ciclos Toda a equipe tem de estar mais integrada Falhas de comunicao so mais frequentes.

Desenvolvimento gil -> uma especializao do desenvolvimento iterativo Preferncia a conversas

do que documentos escritos Pouca documentao gerada A fase de implementao o foco das
pequenas iteraes. Original de 1995 com o nome de desenvolvimento leve Nasceu com a
publicao do manifesto gil em 2001 Agile Alliance promove o desenvolvimento gil Scrum,
eXtreme Programming, Feature Driven Development. Garantir a satisfao do consumidor entregando
rapidamente e continuamente softwares funcionais Softwares funcionais so a principal medida de
progresso do projeto Mudanas tardias de escopo no projecto so bemvindas Cooperao constante
entre pessoas que entendem do 'negcio' e desenvolvedores

Modelos de Casos de Uso

uma representao das funcionalidades externamente observveis do sistema e dos

elementos externos ao sistema que interagem com ele
Foi incorporado logo no inicio da UML. O diagrama de caso de uso o diagrama UML utilizado
nesse modelo. Faz parte da especicao dos requisitos. O mais popular dos diagramas devido
a sua simples notao e linguagem natural. Principal ponte entre desenvolvedores e clientes.
Fora desenvolvedores a moldar o sistema ao cliente e no o cliente ao sistema
Composto por partes textuais e grcas. Trs Componentes bsicos: Casos de Uso, Atores,
Relacionamento entre eles.
a especicao de uma sequncia de interaes entre o sistema e os agentes externos que
utilizam esse sistema.
Representa quem faz o que (interage) com o sistema. Dene o uso de certa funcionalidade do
sistema, sem revelar a estrutura e o comportamento interno. Descrio narrativa das
interaes que ocorrem entre os agentes externos e o sistema. A UML no dene como essa
descrio textual feita.

Descrio contnua do caso de uso Realiza Saque: O Cliente chega ao caixa eletrnico e insere
seu carto, aps o sistema requisita a senha do Cliente para realizar a validao da mesma.
Assim, o Sistema mostra as operaes disponveis e o Cliente pode escolher a opo de saque.
sistema requisita o total a ser sacado para poder fazer a vericao de saldo do Cliente. Depois
dessa validao oSistema disponibiliza o dinheiro e imprime o recibo para o Cliente.

Descrio numerada do caso de uso Realiza Saque:

1 - O Cliente chega ao caixa eletrnico e insere seu carto.

2 - O sistema requisita a senha do Cliente.
3 - O sistema realiza a validao da senha.
4 - O Sistema mostra as operaes disponveis.
5 - O Cliente escolhe a opo de saque.
6 - O Sistema requisita o total a ser sacado.
7 - O Sistema verica
8 - O Sistema disponibiliza o dinheiro e imprime o recibo para o Cliente.

Descrio particionada do caso de uso Realiza

Saque:

Essencial -> No faz meno a tecnologia relacionada . Mais de 1 interface para a mesma
funcionalidade (Internet e Celular) .
Real -> Atrelado a tecnologia a ser utilizada. Regra dos 100 anos (Narrativa ser vlida daqui a
100 anos ?)

Grau de abstrao
1 - Cliente fornece sua identicao 2 - Sistema Identica cliente 3 - Sistema apresenta as
operaes 4 - Cliente solicita o saque de determinada quantia 5 - Sistema verica se Cliente
tem saldo suciente 6 - Sistema fornece a quantia 7 - Cliente recebe o dinheiro
(ESSENCIAL!!)
1 - O Cliente chega ao caixa eletrnico e insere seu carto. 2 - O sistema requisita a senha do
Cliente. 3 - O sistema realiza a validao da senha. 4 - O Sistema mostra as operaes
disponveis. 5 - O Cliente escolhe a opo de saque. 6 - O Sistema requisita o total a ser
sacado. 7 - O Sistema verica 8 - O Sistema disponibiliza o dinheiro e imprime o recibo para o
Cliente.
(REAL!!)

CENRIOS
Caso de uso pode ser realizado de diferentes maneiras . descrio de uma dessas maneiras.
Tambm chamado de instncia de um caso de uso.
Coleo de cenrios utilizado na fase de testes . Novos casos de uso podem ser identicados
E se o cliente fornece a senha errada? E se o cliente no tem saldo? E se o cliente no pega o
dinheiro?

ATORES
Qualquer elemento (agente) externo que interage com o sistema . Externo: Atores no fazem
parte do sistema. Interage: Ator troca (recebe/envia) informaes sobre o sistema
Pessoa (Empregado, Cliente, Gerente, Tcnico) Organizao (Fornecedor, Governo,
Operadora de Carto) Sistemas (Recurso Humano, Estoque, Cobrana) Equipamentos
(Leitora de carto, Sensor de proximidade, Leitor Cdigo de Barras)

O Ator sempre inicia a interao Uma pessoa pode agir como diferentes Atores em um
determinado Caso de Uso Um Funcionrio do banco Pode ser Cliente do banco Um ator
pode participar em vrios casos de uso Um Caso de Uso pode envolver vrios atores. Os
atores podem ser classicados em primrio e secundrio Primrio: Quem inicia a interao e
para o qual o Caso de Uso trar benefcios Secundrio: Supervisionam ou auxiliam na
utilizao do sistema Um Cliente sacando na boca do caixa por um Funcionrio

RELACIONAMENTOS
Um ator deve estar sempre relacionado a um ou mais casos de uso Pode haver
relacionamento inclusive entre casos de uso do sistema UML dene Comunicao
Incluso Extenso Generalizao.
Quais atores esto diretamente associados a quais casos de uso Signica que esse ator troca
informaes com o caso de uso O ator pode se comunicar com 1 ou mais casos de uso.

Relacionamento de Comunicao: Quais atores esto diretamente associados a quais casos de

uso Signica que esse ator troca informaes com o caso de uso O ator pode se comunicar
com 1 ou mais casos de uso.

Representao:

Relacionamento de Incluso: Somente entre casos de uso, nunca entre atores Analogia a
rotina ou funo que desempenha um papel especico Quando 1 ou mais casos de uso
utilizam a mesma rotina/funo Essa rotina descrita como outro caso de uso que ser
incluso por aqueles que a usam

Relacionamento de extenso: Um dos cenrios de um caso de uso (A) podem incluir o

comportamento descrito por outro caso de uso (B) Diferentes sequncias de interao
podem ser inseridas em um nico caso de uso O caso de uso estendido opcional, somente
executado em certas situaes. O Ator que acaba escolhendo se o caso de uso vai ser
executado ou no Aps a execuo da extenso, o mesmo volta a execuo normal O
momento em que as extenses sero executadas so marcadas por pontos de extenso.

Relacionamento de Generalizao: Permite que um caso de uso (ou um ator) herde

caractersticas de outro caso de uso (ou autor) Anlogo a herana em programao orientada
a objeto. Caso de Uso (A) dene uma sequncia que pode ser herdada pelo caso de uso (B)
Caso de Uso (B) pode denir alguma dessas sequncias do caso de uso (A) O Caso de Uso (B)
sempre participar em qualquer relacionamento do caso de uso (A). O ator herdeiro (B) possui
o mesmo comportamento frente ao sistema do ator base (A) O ator herdeiro (B) pode
participar de casos de uso de que o ator base no participa.
RESUMO