Faculdade Santa Terezinha Anhanguera - FAST

Curso de Sistemas de Informao

William Machado de Oliveira
Wellerson Martins
Andr Lus Sousa



Etapas 1 e 2 da ATPS de Fundamentos de Analise Orientada a
Objetos





Taguatinga, 2014
1.1 Resumos Analise e Projeto Orientados a objetos

O primeiro passo antes de comear a programar conhecer uma linguagem de orientada
a objetos.
A Linguagem de Modelagem Unificada (UML) uma notao padro de diagramao.
A UML no orientado a objeto, mas importante conhecer a notao padro, porm no
basta saber a UML e no ser capaz de avaliar um excelente projeto orientado a objeto(POO).
POO est fortemente relacionado atividade pr-requisitos de anlise de requisitos, a
qual inclui escrever casos de uso.
A anlise de requisitos e a Anlise e no Projeto orientado a objetos (A/POO) precisam
ser apresentadas e praticadas no contexto de algum processo de desenvolvimento. Nesse caso,
uma abordagem gil para o bem conhecido Processo Unificado (PU) usada como exemplo
de processo de desenvolvimento iterativo, na qual estes tpicos so introduzidos.
Uma habilidade crucial no desenvolvimento orientado a objeto atribuir, habilmente,
responsabilidade aos objetos de software.
A anlise enfatiza um a investigao do problema e dos requisitos, em vez de uma
soluo, por exemplo, se desejarmos um novo sistema online de comercializao, como ser
usado? Quais sero suas funes?
O projeto enfatiza uma soluo conceitual que satisfaa os requisitos e no sua
implementao.
Durante a anlise orientada a objetos, h uma nfase em encontrar e descrever os objetos
no domnio do problema.
Durante o projeto orientado a objetos, h uma nfase na definio dos objetos de
software e como eles colaboram para satisfao dos requisitos. No final acontece a
implementao dos objetos do projeto Exemplo:
Um jogo de dados no qual um jogador lana dois dados. Se o total for sete, ele
vence; caso contrrio, ele perde.

1 Definir casos de uso
Anlise de requisitos pode incluir narrativas ou cenrios sobre como pessoas usam a
aplicao, estes podem ser escritos como casos de uso.
Nesse caso o caso de uso ser jogar um jogo de dados.
Jogar um jogo de dados: Um jogador pede que os dados sejam lanados. O sistema
apresenta o resultado: se a soma do valor das faces dos dados totalizar sete, ele vence; caso
contrrio, perde.
2 Definir o modelo de domnio
A anlise orientada a objetos se preocupa com a criao de uma descrio do domnio,
a partir da perspectiva dos objetos. H um identificao dos conceitos, atributos e associaes
que so considerados de interesse.
O resultado pode ser expresso em um modelo de domnio, que mostra os conceitos ou
objetos do domnio que so de interesse.
3 Definir diagramas de interao
O projeto orientado a objetos se preocupa com a definio de objetos de software e suas
responsabilidades e colaboraes. Uma notao comum para ilustrar essas colaboraes o
diagrama de sequncia. Ele mostra o fluxo de mensagens entre os objetos de software e assim,
a inovao de mtodos.
4 Definir diagramas de classes de projeto
Alm de uma viso dinmica de objetos colaborativas mostrada nos diagramas de
interao, til criar uma viso esttica nas definies de classes com um diagrama de classes
de projeto.




UML- Linguagem de Modelagem Unificada
uma linguagem visual para especificar, construir e documentar artefatos dos
sistemas. Tem trs modos de aplicar a UML:
UML como rascunho diagramas incompletos e informais, criados para explorar partes
difceis do problema ou espao de solues, explorando o poder das linguagens visuais.
UML como planta de software diagramas de projeto relativamente detalhados.
UML como linguagem de programao especificao executvel completa de um
sistema de software em UML. Cdigo executvel ser automaticamente gerado, mas no
normalmente visto ou modificado por desenvolvedores.
Perspectiva para aplicar UML perspectiva conceitual, perspectiva de especificao
(software), perspectiva de implementao (software).
Perspectiva conceitual os diagramas so interpretados como descrevendo coisas em
uma situao do mundo real ou domnio de interesse.
Perspectiva de especificao descrevem abstraes de software ou componentes com
especificao e interfaces, mas nenhum comprometimento com a implementao.
Perspectiva de implementao os diagramas descrevem uma implementao
particular.
Quando as UML so desenhadas no modelo de domnio elas so chamadas conceitos de
domnio ou classe conceituais:
Classe conceitual coisa ou conceito do mundo real. Uma perspectiva conceitual ou
essencial. O modelo de domnio no PU contm classes conceituais.
Classe de software classe que representa uma perspectiva da especificao ou
implementao de um elemento de software independente do processo ou mtodo.
Classe de implementao classe implementada em uma linguagem orientada a objetos
especifica, como a Java.


Etapa 1.2 Conceitos Gerais de Engenharia de Software

A engenharia de software foi criada por causa de uma crise de software, onde era
necessrio evoluir o modo de criao de software, onde o foco o desenvolvimento dentro
de custos adequados de sistemas de software de alta qualidade.
Software so todos dados documentao e configurao associados, necessrios para
que o programa opere. Um sistema de software consiste, geralmente, de um conjunto de
programas separados; arquivos de configurao do usurio.
A engenharia de software engloba todo processo de produo do software at a
manuteno do sistema aps entrar em funcionamento.
Processo de software toda atividade e resultados na produo do software, porem
existem quatro atividades essncias e comum em todo processo de softwares:
Especificao de software: clientes e engenheiros definem o software a ser produzido
e as restries para a sua operao.
Desenvolvimento de software: O software projetado e programado.
Validao de software: na qual o software verificado para garantir que o que o
cliente deseja.
Evoluo de software: o software modificado para se adaptar s mudanas dos
requisitos do cliente e do mercado.
Para um software ser considerado bom deve conter alguns atributos:
Facilidade de Manuteno: software deve ser escrito de modo que possa evoluir para
atender s necessidades de mudana dos clientes.
Confiana: o nvel de confiana tem uma srie de caractersticas, incluindo
confiabilidade, proteo e segurana. Um software confivel no deve causar danos fsicos
ou econmicos no caso de falha no sistema.
Eficincia: software no deve desperdiar os recursos do sistema, e deve eficincia
no tempo de resposta.
Usabilidade: o software deve usado pelo usurio sem esforos excessivo, tendo uma
interface amigvel e documentao amigvel.
Existem dois tipos fundamentais de desenvolvimento evolucionrio:
Desenvolvimento exploratrio: no qual o objetivo fazer todo processo com o cliente,
onde no decorrer da evoluo do sistema o cliente vai incluindo novas caractersticas.
Prototipao throwaway: o objetivo compreender todos os requisitos passados pelo
cliente e procurar desenvolver com a melhor soluo possvel.
Porem do ponto de vista da engenharia e do gerenciamento esses processos no so
viveis, porque o sistema desenvolvido rapidamente comprometendo sua qualidade.

Engenharia de software baseada em componentes

Esses componentes so sistemas comerciais independentes que podem fornecer
funcionalidade especifica como a formatao de texto ou um calculo numrico.
Apresenta os seguintes estgios:
Anlise de componentes: aps a especificao dos requisitos, feita uma busca de
componentes para implementar essa especificao.
Modificao de requisitos: so modificados para refletir os componentes disponveis.
Projeto de sistema com reuso: o framework do sistema projetado ou um framework
existente reusado.
Desenvolvimento e Integrao: o software que no pode ser adquirido externamente
desenvolvido e os componentes e os sistemas so integrados para criar o novo sistema.

Desenvolvimento em espiral

O desenvolvimento em espiral representado como espiral e cada loop na espiral
representa uma fase do processo de software. E cada loop na espiral est divido em quatro
setores:
Definio de objetivos: os objetivos especficos dessa fase so definidos como
restries sobre o processo e o produto identificado e um plano detalhado de
gerenciamento elaborado.
Avaliao e reduo de riscos: para cada risco de projeto identificado, uma anlise
detalhada realizada.
Desenvolvimento e validao: aps a avaliao de risco, um modelo de
desenvolvimento para o sistema selecionado.
Planejamento: o projeto revisado e uma deciso tomada para prosseguimento ao
prximo loop da espiral. Se a deciso for pelo prosseguimento, sero elaborados planos para
a prxima fase do projeto.

Especificao de software

A especializao de software ou engenharia de requisitos o processo para
compreender e definir quais servios so necessrios e por isso um estgio
particularmente crtico do processo do software, por que qualquer erro causara problemas
na continuao do projeto e na implementao.Com base nessa produo existe um
documento de requisitos, que a especializao do sistema. Existem quatro fases principais
no processo de engenharia de requisitos:
Estudo de viabilidade: feita uma avaliao para verificar se as necessidades dos
usurios. E tem estudo de custo adequado do ponto de vista comercial e se pode ser
desenvolvido.
Elicitao e analise de requisitos: o processo de derivao de requisitos de sistema
atravs da observao de sistemas existentes, discusses com usurios potenciais e
compradores. Pode envolver o desenvolvimento de um ou mais modelos de sistema e
prottipos.
Especificao de requisitos: atividade de traduzir as informaes coletadas durante a
atividade de anlise em um documento que define um conjunto de requisitos.
Validao de requisitos: essa atividade verifica os requisitos em relao ao realismo,
consistncia e abrangncia.
















Etapa 1.3 Concepo, Elicitao e Tipos de Requisitos

Concepo uma fase relativamente curta para a maioria dos projetos, geralmente
com uma ou duas semanas, se houver mais de duas semanas seu sentido provavelmente foi
mal compreendido.
A concepo, em uma frase:
Conceber o escopo do produto, a viso e o caso de negcio.
O problema principal a ser resolvido, em uma frase:
Os interessados no projeto do sistema tem um consenso bsico sobre a viso do projeto
e vale a pena investir em uma investigao sria?
O objetivo da concepo estabelecer uma viso inicial comum para os objetivos do
projeto, determinar se mesmo vivel e decidir se ele realmente deve passar por uma
investigao mais seria na fase de elaborao.
Alguns artefatos comuns da concepo e indica os aspectos que eles devem abordar,
lembrando que o contedo da investigao e dos artefatos deve ser leve:
Viso e caso de negcio: descrevem os objetivos e as restries de alto nvel, o caso de
negcio, alm de um resumo para executivos.
Modelo de casos de uso: Descreve os requisitos funcionais.
Especificaes suplementares: Descrevem outro requisitos, a maior parte no funcional.
Sendo a finalidade da concepo coletar apenas informaes para estabelecer uma viso
comum, e talvez o uso de UML no ter muita diagramao, por que o escopo e 10% dos
requisitos expresso em forma de texto.



Elicitao
A elicitao de requisitos uma fase muito importante em qualquer projeto de
desenvolvimento de software, pois se elaborada de maneira incorreta, todo o projeto estar
comprometido.
Elicitao promovido por meio de tcnicas como: escrever os casos de uso com os
clientes, promover seminrios de requisitos que incluem tanto desenvolvedores quanto
clientes, enfocarem grupos com pseudoclientes e uma demonstrao dos resultados de cada
iterao para os clientes, para solicitar realimentao.

Tipos de requisitos e categorias

No PU, os requisitos so categorizados de acordo com o modelo FURPS+[Grady92]
Funcional: caractersticas, capacidade, segurana.
Usabilidade: fatores humanos, recursos de ajuda, documentao.
Confiabilidade: frequncia de falhas, capacidade de recuperao, previsibilidade.
Desempenho: tempos de resposta, fluxo de vazo, preciso, disponibilidade, uso de
recursos.
Alguns desses requisitos so coletivamente chamados de atributos de qualidade,
requisitos de qualidade ou as Idades de um sistema. Estas incluem a usabilidade, a
confiabilidade, o desempenho e a facilidade de suporte. No uso comum, requisitos so
categorizados como funcionais (comportamentais) ou no funcionais (todos os outros);
alguns desaprovam essa generalizao ampla [BCK98], mas ela bastante usada.



Etapa1. 4 Engenharia de Requisitos

As descries das funes e das restries so requisitos para o sistema, e o processo
de descobrir, analisar, documentar e verificar essas funes e restries chamado de
engenharia de requisitos.
O termo engenharia implica na adoo de mtodos e tcnicas sistemticas, de tal forma
que o processo seja passvel de repetio e garanta a definio de requisitos no
redundantes, completos, correto, de fcil entendimento.
Requisito pode ser definido como algo que um cliente necessita, ou de vista de um
desenvolvedor como algo que necessita ser projetado.
Requisitos de sistema x Requisitos de software
Requisitos de sistema: tem um contedo mais amplo e menos tcnico que requisitos
de software, alm de descrever o comportamento do sistema visto pelo o usurio e serve de
veculo de comunicao entre os usurios e os desenvolvedores de software.
Requisitos de software: a maior parte dos requisitos do sistema apontados pelos
usurios so funcionalidades e restries que devem ser suportadas pelo software a serem
implementados, e por tanto passam a ser vistos tambm como requisitos de software.
Requisitos Funcionais x No funcionais
Requisitos Funcionais: Determinam o que o software deve fazer, so identificados a
partir do ponto de vista do usurio.
Requisitos no funcionais: Determinam as caractersticas desejveis do software
quanto a desempenho, confiabilidade, segurana, portabilidade, etc...



Elicitao de requisitos

Na elicitao, usurios e desenvolvedores trabalham em conjunto para compreender o
problema apresentado.
Porem essa atividade no engloba apenas o usurio deseja, mas requer uma anlise
criteriosa sobre onde o sistema ser implantado, uma anlise do domnio da aplicao e dos
processos de negcios onde o software ser utilizado.
No decorrer da elicitao podem ocorrer problemas que so considerados em dois
grupos: os problemas acidentais e essncias.
Os problemas acidentais ocorrem quando foi mal levantado os requisitos junto com o
usurio.
Os problemas essenciais ocorrem quando os usurio tem dificuldade de explicar o que
ele quer exatamente, causando dificuldade de o desenvolvedor compreender os requisitos
solicitados.

Anlise de requisitos

Analise de requisitos est diretamente vinculada com a elicitao, onde o objetivo
encontrar possveis problemas levantados pelo requisitos feito pela elicitao na declarao
informal.
Verificao de necessidade, verificao de consistncia e completude e verificao de
possibilidade so os trs elementos fundamentais que auxiliam na identificao de
problemas nos requisitos.
A especializao de requisitos resulta em documentos que organizam os requisitos
obtidos, e esses documentos tambm so chamados de artefatos de software.
A etapa final a validao de requisitos, onde o principal objetivo verificar e validar
todos os requisitos especificados, essa etapa engloba tanto os desenvolvedores como o
prprio usurio, procurando identificar possveis problemas.
O gerenciamento de requisitos envolve as mudanas que ocorrem nos requisitos do
sistema, procurando melhor atender o usurio.


















Etapa3 Requisitos

O sistema deve manter gerenciamento de passageiros (incluir, excluir, editar).
O sistema deve permitir gerenciar as bagagens dos passageiros por voo.
O sistema deve conter informaes sobre as caracterizas tcnicas das aeronaves.
O sistema deve manter lista de voos (incluir, excluir, editar).
O sistema deve manter passageiros por voo (incluir, excluir, editar).
O sistema deve controlar o armazenamento de bagagens no compartilhamento de carga.
O sistema deve controlar as rotas de voos.
O sistema deve ser acessado por usurios autorizados.
O sistema deve fazer um backup um vez por dia.


Requisitos Funcionais

RF1 O sistema deve manter gerenciamento de passageiros (incluir,
excluir, editar).
RF2 O sistema deve permitir gerenciar as bagagens dos passageiros por
voo.

RF3 O sistema deve conter informaes sobre as caracterizas tcnicas
das aeronaves.
RF4 O sistema deve manter lista de voos (incluir, excluir, editar).

RF5 O sistema deve manter passageiros por voo (incluir, excluir,
editar).
RF6 O sistema deve controlar o armazenamento de bagagens no
compartilhamento de carga.

RF7 O sistema deve controlar as rotas de voos.


Requisitos no funcionais

RNF1 O sistema deve ser acessado por usurios autorizados.
RNF2 O sistema deve fazer backup um vez por dia.












Resumo2.1 Caso de Uso

Caso de Uso so narrativas de texto utilizada para descobrir e registrar requisitos, so
muito uteis pois destacam os objetivos e perspectivas do usurio. Segundo Craig Larman
casos de uso so requisitos funcionais ou comportamentais que indicam o que o sistema fara,
mas tambm podem ser usados para definir outros tipos de requisitos. Caso de uso uma
coleo de cenrios relacionados de sucesso e fracasso, que descrevem um ator usando um
sistema como meio para atingir um objetivo.
Ator e um sistema, organizao ou uma pessoa algo com comportamento. Cenrio e
uma sequencia especifica de aes.
Caso de uso pode ser escrito em formatos e nveis diferentes de formalidade.
Resumido: resumo de um paragrafo o cenrio principal
Informal: vrios pargrafos com vrios cenrios.
Completo: Descrio detalhada de todos os cenrios.
Um caso de uso deve conter nome(comear por um verbo, incluir, consultar, alterar,
excluir por exemplo); escopo(o sistema em projeto); fluxo de eventos bsico(comtempla o
inicio e o fim do caso de uso); alternativo(ramifica o caso de uso para outros cenrios); fluxos
de exceo( uma validao no sistema, caso no ocorra algo como esperado dentro do
contexto).
Existem algumas diretrizes para orientar em como encontrar casos de uso
Escolher os limites do sistema, quem usara o sistema.
Evidenciar os atores principais e os objetivos para cada ator.
Definir casos de uso que satisfaam os objetivos do cliente
importante escrever casos de uso simples que facilitem o entendimento, isso evita
perder referncias e aumenta a interao com o clientes, o fracasso de muitos projetos se da
por causa da falta de interao com o cliente.

Resumo 2.2 Diagramas Casos de Uso

Resumo sobre Diagramas de Caso de Uso do Professor Tiago Salhab Alves, mestre em
Cincias da Computao e Especialista em Didtica e Metodologia do Ensino Superior.
Os diagramas de caso de uso costumam conter casos de uso na forma de
representaes grficas Atores e Relacionamentos, que podem ser de generalizao,
Associao. Estes diagramas ilustram os passos do caso de uso para facilitar o entendimento
das partes envolvidas.
Caso de uso e uma sequencia de aes que um sistema executa para produzir um
resultado de valor observvel por um ator. Nos diagramas o caso de uso e representado por
uma elipse, todo caso de uso deve ter um nome que o diferencie e deve comear por um
verbo.
Relacionamento de Generalizao representada por uma linha solida com um triangulo
numa das pontas o triangulo aponta para o caso de uso pai. Generalizao e quando um caso
de uso filho herda o comportamento e o significado do caso de uso pai.
Associao e uma ligao que pode ocorrer entre o ator e o caso de uso. Representada
com uma seta solida, que pode vir acompanhada de um estereotipo (papel) os mais comuns
so <<incluso>> <<extenso>>.
Incluso indica que o caso de uso base incorpora explicitamente o comportamento do
outro caso de uso.
Extenso quando o caso de uso base incorpora opcionalmente o comportamento do
caso de uso estendido.





Resumo 2.3 Diagramas de Classe UML

Resumo do capitulo sobre Diagramas de Classe UML do livro: Utilizando UML e
padres do autor Craig Larman.
Os diagramas de classe ilustram classes interface e suas associaes, so usados para
modelagem esttica de objetos. Pode ser usado para visualizar um modelo de domnio e
diagrama de classes de objeto.
Classificador UML segundo Craig Larman, Classificador um elemento de modelo
que descreve caractersticas comportamentais e estruturais. Podem ser especializados e so
umas generalizaes de classes, interfaces, casos de uso e atores. Os atributos de um
classificador podem ser mostrados em notao textual de atributo, notao de linha de
associao ou ambas juntas. Geralmente atributos so considerados privados. Usam-se setas
navegadoras para indicar os atributos do objeto alvo.
Operao UML uma declarao, com um nome, parmetros, tipo de retorno, lista de
excees e possivelmente, um conjunto de restries de pr e ps-condies.
Mtodo em UML e uma ao implementao de uma operao
Operaes de acesso recuperam ou atribuem valores a atributos.
Propriedade e um valor que denota uma caracterstica de um elemento.
Generalizao um relacionamento entre um classificador mais geral e um
classificador mais especifico.
Dependncia e quando dois elementos esto relacionados e h alterao de um afeta o
outro, ela e ilustrada com uma linha tracejada, seta partindo do cliente para fornecedor. Tipos
comuns de dependncia um tipo de fornecedor. A visibilidade do fornecedor poderia ser um
atributo, uma varivel de parmetro, varivel local, varivel global. Receber um parmetro do
tipo fornecedor e uma superclasse ou interface.
A UML fornece vrios modos de mostrar implementao de interface, fornecendo uma
interface para clientes e dependncia de interface.
Agregao espcie vaga de associao na UML. Agregao Composta e uma espcie
forte de agregao.
Associao qualificada tem um qualificador que e usado para selecionar um objeto a
partir de um conjunto maior de objetos relacionados.
Classe Associativa permite tratar uma associao em si como uma classe modela-la
com atributos, operaes e outras caractersticas.
Classe Objeto Unitrio uma instancia de uma classe instanciada nunca duas.
Classe ativa um objeto ativo executa e controla sua prpria linha de execuo.