Anlise Orientada a Objetos

Prof. Vtor Souza Anlise e Projeto Orientado a Objetos

11/04/2006 Departamento de Informtica Univ. Federal do Esprito Santo

Licena para uso e distribuio

Este material est disponvel para uso no-comercial e pode ser derivado e/ou distribudo, desde que utilizando uma licena equivalente. Atribuio-Uso No-ComercialCompatilhamento pela mesma licena, verso 2.5 http://creativecommons.org/licenses/by-nc-sa/2.5/deed.pt
Voc pode copiar, distribuir, exibir e executar a obra, alm de criar obras derivadas, sob as seguintes condies: (a) voc deve dar crdito ao autor original, da forma especificada pelo autor ou licenciante; (b) voc no pode utilizar esta obra com finalidades comerciais; (c) Se voc alterar, transformar, ou criar outra obra com base nesta, voc somente poder distribuir a obra resultante sob uma licena idntica a esta.

Sobre o curso
Estes slides foram criados no Departamento de Informtica da Universidade Federal do Esprito Santo (UFES) e esto disponvel no seguinte endereo: http://www.inf.ufes.br/~vsouza/ O material usado como base foi cedido pelo professor Dr. Ricardo de Almeida Falbo, do DI/UFES: http://www.inf.ufes.br/~falbo/ Este curso tem como objetivo apresentar os conceitos da anlise e projeto orientado a objetos a profissionais e estudantes de Engenharia de Software.

Processo de desenvolvimento
O que um processo?
Entrada Processamento Sada

Principais componentes de um processo:

Atividades; Artefatos (insumos e produtos); Recursos; Procedimentos.

So necessrios?
Em pequenos projetos, podem no ser; Em grandes projetos, eles:
Formalizam a comunicao; Guiam o desenvolvimento; Auxiliam na garantia da qualidade.

O que qualidade?
Um sistema correto, rpido, confivel, fcil de usar, eficiente, etc.; Um sistema fcil de entender, de modificar, reutilizvel, portvel, etc.

Como escolher um processo?

Depende de vrios fatores:
Produto a ser desenvolvido; Time de desenvolvimento; Cliente; Rigor em relao documentao; Limites de prazo e custo; Etc.

Definio do processo
Definio das atividades-chave:
Planejamento, requisitos, anlise, projeto, etc.

Escolha de um paradigma:
Orientado a Objetos, Estruturado, etc.

Escolha de um modelo de ciclo de vida:

Linear, incremental, evolutivo, etc.

Atividades-chave
Planejamento; Levantamento de Requisitos; Anlise; Projeto; Implementao; Testes; Implantao; Operao; Manuteno.

Planejamento
Definio de estimativas de custo, tempo e utilizao de recursos; Plano de projeto: proposta de desenvolvimento, definio do processo; Informaes atualizadas regularmente (revises a cada final de etapa).

Levantamento de requisitos
Refinamento do escopo; Identificao dos requisitos; Compreenso do domnio do problema.

Anlise
Modelagem, avaliao e documentao dos requisitos; Foco no que o software deve fazer, e no em como ele far.

Projeto
Definio da plataforma de implementao; Incorporao de requisitos tecnolgicos; Foco em como cada requisito ser implementado; Refinamentos sucessivos at chegar ao nvel de implementao.

Implementao
Traduo do projeto para uma linguagem de programao; Objetiva ter um software executvel.

Testes
Validao da funcionalidade por parte do time de desenvolvimento; Diversos tipos:
Testes de unidade; Testes de integrao; Testes de sistema; Testes de carga/estresse; Etc.

Implantao
Colocao do sistema em produo; Envolve outros aspectos:
Treinamento de usurios; Configurao do ambiente; Converso de tecnologias; Etc.

Validao das funcionalidades por parte do usurio.

Operao
Software em utilizao pelo cliente.

Manuteno
Alteraes no software:
Erros encontrados; Adaptaes a alteraes do ambiente; Funcionalidade adicional; Ajuste fino; Etc.

Pode requerer a definio de um novo processo de software.

O paradigma
Vantagens do paradigma OO:
Mesma notao durante todo o processo; Reduo do gap semntico; Promove desenvolvimento incremental e evolutivo; Reusabilidade; Extensibilidade; Modularidade; Etc.

O modelo de ciclo de vida

Estrutura as atividades do processo em fases e define como se relacionam; Muitos se encaixam no paradigma OO; Exemplos:
Seqencial linear; Incremental; Evolutivos; geis.

Modelo seqencial linear

Mais antigo e mais fcil de gerenciar; Fases executadas uma vez, em seqncia; Vrias fraquezas:
Projetos reais no seguem o fluxo seqencial; No acomoda incertezas; Demora para produzir algo concreto; No otimiza a alocao de recursos humanos.
A1 A2 A3 Em Cascata

Modelo incremental
Variao do seqencial linear; Levantamento de requisitos e anlise so feitos seqencialmente; Projeto, implementao e testes so feitos em incrementos; Cada incremento gera uma parte operacional do sistema.

Modelos evolutivos
Premissa de que os requisitos evoluem ao longo do tempo; Em geral so processos iterativos; Cada iterao constri um incremento de software, que evolui com o tempo.

Evolutivo bsico

Modelo espiral

Rational Unified Process (RUP)

Modelos geis
Nova filosofia que valoriza:
Indivduos e interaes ao invs de processos e ferramentas; Software funcional ao invs de documentao; Colaborao ao invs de negociao; Responder s mudanas ao invs de seguir um plano.

Exemplos:
Extreme Programming (XP); Agile Modeling; SCRUM; Etc.

Exemplo de processo OO

Planejamento

Levantamento de Requisitos

Anlise OO

Plano de Projeto

Especificao de Requisitos

Especificao de Anlise

Exemplo de processo OO

Projeto OO

Implementao

Testes

Especificao de Anlise

Especificao de Projeto

Cdigo-Fonte

Neste curso...
J vimos Levantamento de Requisitos:
Resumo de Engenharia de Requisitos; Tcnicas de levantamento de requisitos; Modelagem de casos de uso.

Veremos Anlise OO:

Identificao de classes, hierarquias, associaes a atirbutos; Identificao de subsistemas; Identificao de comportamento e operaes.

A Linguagem de Modelagem Unificada (UML)

11/04/2006

Prof. Vtor Souza Anlise e Projeto Orientado a Objetos

Departamento de Informtica Univ. Federal do Esprito Santo

Unified Modeling Language

Padro de facto para especificar, visualizar, documentar e construir artefatos de um sistema desenvolvido sob o paradigma Orientado a Objetos; Nasceu para o paradigma OO, mas no exclusiva para ele; Teve origem em trs outros mtodos:
OMT (Rumbaugh et al., 1994); Mtodo de Booch (Booch, 1994); Mtodo OOSE (Jacobson, 1992).

UML
Aprovada e homologada pela OMG (Object Management Group) em 1997. Sua verso atual 2.0; A notao pode ser unificada, mas a deciso de qual artefato produzir depende do processo definido para o projeto; Pode ser utilizada em diferentes processos de desenvolvimento orientados a objetos, em todas as etapas do ciclo de desenvolvimento.

Diagramas da UML
de Casos de Uso; de Classes; de Objetos; de Estrutura Composta; de Seqncia; de Comunicao; de Estados; de Atividades; de Componentes; de Implantao; de Pacotes; de Interface Geral; de Tempo.

Diagramas de casos de uso

Modela as funcionalidades do sistema; Captura tpicas interaes usurio sistema; Usurios so atores; Atores e casos de uso so associados; Cada caso descrito em detalhes separadamente.

Diagramas de classes

Classe Abstrata Classe Associativa Nome Atributos Operaes

Herana

Associao (e suas cardinalidades) Agregao Classe

Diagramas de estados

Estado Inicial Transio Estado

Estado Final

Diagramas de seqncia
Ator Objeto

Mensagem

Retorno

Condio Excluso

Modelagem esttica
11/04/2006

Prof. Vtor Souza Anlise e Projeto Orientado a Objetos

Departamento de Informtica Univ. Federal do Esprito Santo

Anlise orientada a objetos

Modelagem esttica:
Identificao de classes; Especificao de hierarquias de generalizao/especializao; Identificao de subsistemas; Identificao de associaes e atributos.

Modelagem dinmica:
Determinao do comportamento; Definio de operaes.

Classes
Em ltima instncia, um sistema OO um conjunto de objetos que se comunicam; Objetos so categorizados em classes; No modelamos objetos, modelamos classes; Logo, o processo central da Anlise OO a descoberta de classes que devem ser includas no modelo.

Como identificar classes?

Internalize os conceitos OO; Analise os requisitos (documento e casos de uso) estude o domnio do problema; Facilitadores:
Faa uma anlise gramatical dos casos de uso; Observe o ambiente do problema; Procure ouvir atentamente os especialistas; Verifique resultados de anlise OO anteriores; Observe outros sistemas; Consulte fontes bibliogrficas.

Possveis candidatos classes

Coisas que so parte do domnio do problema:
Ex.: pessoas, clientes, turmas, produtos, etc.

Papis desempenhados pelas diferentes pessoas que interagem direta ou indiretamente com o sistema:
Ex.: piloto, atendente, gerente etc.

Ocorrncias ou eventos que precisam ser registrados e lembrados pelo sistema:

Ex.: reclamao do cliente, reunio, etc.

Locais fsicos ou geogrficos e lugares que estabelecem o contexto do problema:

Ex.: loja, aeroporto, etc.

Unidades organizacionais (departamentos, divises etc) que possam ser relevantes para o sistema:
Ex.: local para entrega, setor, etc.

Critrio para seleo

Uma classe deve:
Reter informaes teis; Prover servios que so requeridos pelos usurios (e inerentes fase de anlise); Ter mais de um atributo; Ter mais de uma instncia; Ter atributos e operaes que so comuns a todas as suas instncias.

Como modelar classes?

Representao em UML
Nome da Classe <Lista de atributos> <Lista de operaes>

Se estiver em itlico, a classe abstrata. Sintaxe: <escopo> <nome> : <tipo> = <valor default> Escopo: - privado + pblico # protegido Tipo: ignorado na fase de anlise. Sintaxe: <escopo> <nome> (<parmetros>) : <tipo> <parmetros> = lista de pares <nome> : <tipo>, separada por vrgula. Tipo: ignorado na fase de anlise.

Aps identificadas, so dispostas em diagramas de classes.

Hierarquias
Um dos principais mecanismos de estruturao de conceitos; Captura similaridades entre classes.

Especializao

Generalizao

Diretrizes para herana

Deve modelar relaes -um-tipo-de;
Instncias da subclasse so por definio instncias da superclasse. Tudo que dito para esta ltima vale para a primeira.

Subclasses devem suportar toda a funcionalidade das superclasses e possivelmente mais; Funcionalidade comum a diversas classes deve estar o mais alto possvel na hierarquia; A herana deve estar no domnio do problema e fazer parte das responsabilidades do sistema; Classes que no adicionam funcionalidade nem redefinem funcionalidades existentes devem ser eliminadas.

Separao em subsistemas
Projetos grandes podem conter centenas de classes e estruturas diversas; Diviso das classes em pacotes:
Coleo de classes que colaboram entre si; Conjunto coeso de responsabilidades; Caixa preta.

Vantagens:
Facilita o entendimento para leitores; Auxilia na organizao de grupos de trabalho; Organiza a documentao.

Pacotes de classes x subsistemas

Casos de uso podem ser um bom ponto de partida para definio do agrupamento; No entanto, no obrigatrio que a diviso seja a mesma; Apresenta-se um diagrama de pacotes e cada pacote possui um diagrama de classes prprio.

Associaes entre pacotes

Nos pacotes de classes: classes do Pacote 02 aparecem no diagrama de classes do Pacote 01 (como se fossem importadas).

Nos pacotes de casos de uso: casos de uso do Subsistema 01 dependem (<<include>>, <<extends>>, etc.) de casos de uso do Subsistema 02.

Identificando relacionamentos
Classes se relacionam por meio de associaes simples, agregaes ou composies; Indicam possveis ligaes entre os objetos das classes associadas.

Cardinalidades
Indicam quantos objetos podem participar de um determinado relacionamento.
Objetos da ClasseA podem se relacionar com no mnimo zero e no mximo trs objetos da ClasseB.

Um e somente um.

Nenhum, um, ou vrios.

Papis
Indicam o papel que a classe desempenha na associao (so usados substantivos); opcional, usado quando melhora o entendimento do modelo; Sintaxe: <escopo> <nome>.

Relacionamentos n-para-n
Perfeitamente legais; Requerem ateno possveis atributos do relacionamento (eventos a serem lembrados).

requisito do sistema armazenar data de incio e fim da alocao de um funcionrio a um projeto?

Classes associativas

Relacionamentos recursivos
Perfeitamente legais; Geralmente pedem definio de papis.

Associaes n-rias
Associaes entre trs ou mais classes; Extremamente raras, muitas vezes as ferramentas CASE nem do suporte.

Agregao e composio
Tipos especiais de associao, j estudados.

Qual a semntica da agregao

No h consenso; Uma viso:
Na agregao ou composio, as partes s podem existir como membros do todo; A composio difere da agregao por restringir que a parte s participe de 1 todo.

Outra viso:
Na agregao, as partes podem existir sem o todo e viceversa; A composio difere da agregao por restringir que o todo no vive sem as partes.

Atributos de classes
Atributos so informaes de estado (propriedades) para o qual cada objeto em uma classe tem seu valor; Muito similares s associaes:
Como atributos tm um tipo, podemos considerar que so associaes com um tipo; Para tipos primitivos definimos atributos, do contrrio modelamos uma associao; Em ltima instncia, associaes e atributos so implementados da mesma forma; Atributos e associaes definem uma classe.

Como identificar atributos

Quatro passos:
Descoberta de atributos; Posicionamento dos atributos em uma hierarquia de classes; Reviso da hierarquia de classes; Especificao dos atributos.

Descoberta de atributos
No h mgica. Usamos as mesmas tcnicas da descoberta de classes; Caractersticas de um atributo:
Informao relevante no contexto do problema; Captura um conceito atmico (do contrrio seria uma classe).

Muitas classes identificadas e que no passam nos critrios de classe podem vir a ser atributos.

Posicionamento de atributos
Ateno hierarquias de classes:
Atributos genricos ficam mais acima na hierarquia; Por outro lado, se ele no se aplica a algumas subclasses, deve ser trazido para baixo, somente para as classes apropriadas.

Reviso da hierarquia:
Descoberta de atributos nos leva a um melhor entendimento, o que possivelmente implicar reviso de hierarquias.

Especificao de atributos
Escolha um nome com significado; Siga um padro de nomenclatura; Inclua-o na modelagem de classes:

Dicionrio de dados
Includo na especificao de anlise; Descreve cada atributo:
Seu significado no domnio; Unidades de medida; Intervalo / limite; Enumerao; Preciso; Valor default; Obrigatoriedade; Etc.

Modelagem dinmica
11/04/2006

Prof. Vtor Souza Anlise e Projeto Orientado a Objetos

Departamento de Informtica Univ. Federal do Esprito Santo

Comportamento dinmico
Os diagramas de classes representam apenas elementos estticos, dados; preciso, ainda, representar o comportamento da aplicao em funo do tempo e de eventos especficos; Modelar o comportamento:
Indica como o sistema ir responder a eventos ou estmulos externos; Auxilia o processo de descoberta das operaes das classes do sistema.

Modelos da UML
Diagramas de Estados:
Descrevem os estados possveis pelos quais um particular objeto pode passar e suas transies, estmulos e atividades;

Diagramas de Interao:
Descrevem como grupos de objetos colaboram entre si em um certo comportamento.

Diagrama de Mquina de Estados

Similar ao Diagrama de Transio de Estados (DTE), do paradigma Estruturado; Construdo para uma nica classe; Mostra o comportamento dos objetos desta classe ao longo do tempo:
Estados possveis; Eventos que alteram estado; Caractersticas de cada estado; Etc.

Notao
Estado Inicial Estado Final

Transio

Estado

Estados
Nome: deve descrever claramente o estado; Atividades:
De entrada: ocorrem ao entrarmos no estado; De sada: ocorrem ao sarmos do estado; Convencional: ocorrem enquanto o objeto estiver naquele estado.

Estados inicial e final

Os estados ligados ao estado inicial so aqueles nos quais o objeto pode estar logo quando for construdo;
Deve haver um e somente um estado inicial;

Os estados ligados a um estado final so aqueles dos quais o objeto no mais sair;
No obrigatrio ter e pode ter mais de um; Um estado ligado a um estado final no pode ter transies para outros estados.

Eventos, condies e aes

Indicam a possibilidade de ir de um estado a outro;
Evento: evento externo que motivou a transio; Condio de guarda: condio necessria para efetuar a transio (alm do evento); Ao: ao realizada durante a transio.

Ao x atividade
Ao x atividade convencional:
Uma ao ocorre durante a transio (ela atmica); Uma atividade ocorre enquanto o objeto permanece no estado (quando ela acabar, ele muda de estado);

Ao x atividades de entrada/sada:
Caso s haja uma transio de entrada/sada, no h diferena na prtica.

Exemplos
Ao ser criado, o objeto da classe em questo encontra-se no estado E-1.

Se o objeto estiver no estado E-1 e ocorrer o evento E, se a condio C = true, ocorre a ao A e o objeto passa para o estado E-2.

Enquanto estiver no estado E-1, o objeto realiza a atividade A. Ao terminar a atividade A, automaticamente ele muda para o estado E-2.

Como identificar estados

Somente para algumas classes:
Que possuam comportamento varivel no tempo em cada estado se comportam de maneira diferente; Nas quais seja possvel identificar ao menos trs estados distintos; Cujo passado influencia no seu comportamento atual;

Um estado uma situao durante a vida de um objeto durante a qual ele satisfaz alguma condio, realiza alguma atividade ou aguarda algum evento.

Como identificar transies

Dado um estado, verificamos para quais outros estados ele pode passar e o evento em que isso ocorre; Na grande maioria das vezes, os casos de uso ou cenrios so os eventos que acionam as transies; Aps identificadas, avalie condies de guarda e aes.

Dicas prticas
Preste ateno nas classes prximas, pois podem ser alvos de aes ou participar de condies; Identifique na especificao os eventos aos quais os objetos da classe devem responder; Se um estado for muito complexo, considere criar um subdiagrama s para ele; Verifique se todas as aes esto condizentes com sua modelagem de classes; Simule o sistema em execuo e procure estados noalcanveis, loops ou deadlocks.

Mais um exemplo

Diagramas de interao
Ajudam a compreender e capturar o fluxo global de controle; Modelam um conjunto de objetos e as mensagens que trocam; Foco em uma funcionalidade especfica (caso de uso); Dois tipos de diagrama:
Diagrama de Sequncia (temporal); Diagrama de Colaborao (estrutural).

Diagramas de seqncia
Foco no tempo e no controle; Usaremos como uma formalizao de um fluxo de um caso de uso / cenrio.

Notao geral
Classe Objeto

F L U X O

Escopo

Retorno Marcador de iterao

Linha de vida do objeto

Criao de objetos

Excluso de objetos
referncia a um objeto

Condicionais e loops
Para loops: [for i = 0; i < 10; i++] ou [for each obj in lista]

UML 2.0

Diagrama de colaborao
nfase na organizao dos objetos que participam da interao; Notao similar a grafos: objetos so vrtices e mensagens so arestas.

Exemplo