08asemana ModSist Prof Anderson Siqueira PDF

Anlise e Desenvolvimento de
Sistemas
Modelagem de Sistemas
3 Mdulo 8 Semana
Prof Anderson Siqueira

2017
Casos de uso
E o documento de especificao (4 semana)
MDC & especificao
Casos de uso & Especificao
Prof Anderson Siqueira 8 Semana - Abril / 2017.1 3

Conceitos importantes de projeto
Acoplamento e coeso
Conceitos de Projeto
Acoplamento & coeso
Dois princpios de projeto, dentre outros so: acoplamento e a

coeso;
A coeso uma medida do quo fortemente relacionadas e

focalizadas so as responsabilidades de uma classe;
extremamente importante assegurar que as

responsabilidades atribudas a cada classe sejam altamente
relacionadas.
Em outras palavras, o projetista deve definir classes de tal

forma que cada uma delas tenha alta coeso.

Acoplamento & coeso (continuao)
Coeso (continuao):
Na prtica o indcio de que uma classe tem baixa coeso:
Apresentar dois ou mais grupos de atributos semelhantes

DENTRO dos grupos;
Contudo atributos diferentes ENTRE os grupos;
O mesmo ocorre com os mtodos.

Exemplo de BAIXA coeso Exemplo de ALTA coeso

O acoplamento uma medida de quo fortemente uma

classe est conectada a outras classes, tem
conhecimento ou depende das mesmas;
Uma classe com acoplamento fraco (baixo) no depende

de muitas outras:
Por outro lado, uma classe com acoplamento forte

menos inteligvel isoladamente e menos
reutilizvel.

Exemplo de ALTO e BAIXO acoplamento:

Alm disso, uma classe com alto acoplamento mais

sensvel a mudanas, quando necessrio modificar as
classes da qual ela depende;
PORTANTO criar modelos com alta coeso e baixo

acoplamento deve ser um objetivo de qualquer projetista.

Nivelamento
Eventos de um Software
Eventos de um software ou sistema
Eventos de sistema correspondem s aes do ator no cenrio de

determinado caso de uso;
Sendo assim, relativamente fcil identificar eventos de sistemas

em uma descrio de caso de uso: devemos procurar nessa
descrio os eventos que correspondem a aes do ator;
No caso particular em que o ator um ser humano e existe uma

interface grfica para que o mesmo interaja com o sistema, os
eventos do sistema so resultantes de aes desse ator sobre essa
interface grfica, que corresponde a objetos de fronteira (Boundary).
Exemplo: cliques.

Nivelamento
Eventos de um Software: exemplos
Eventos de um software ou sistema (continuao)
Item
Crditos: Srgio Furgeri, disponvel em http://www.sergio.pro.br/trabalhos/46_delphi_manipulacao_de_listbox_combobox_e_imagens.pdf

Crditos: Srgio Furgeri, disponvel em http://www.sergio.pro.br/trabalhos/46_delphi_manipulacao_de_listbox_combobox_e_imagens.pdf

Considere o formulrio a seguir, para o caso de uso (do SCA)

denominado "Fornecer Grade de Disponibilidades (Bezerra, 2007):

No formulrio anterior, temos a seguinte lista de eventos de

sistema:
Solicitao de validao de matrcula de professor;
Solicitao de adio de uma disciplina grade;
Solicitao de adio de um item de disponibilidade (dia,

hora inicial e hora final) grade;
Solicitao de registro da grade.

Diagrama de Classes
Anlise dos casos de uso
Diagrama de Classes
Anlise
Identificao de classes:
Apesar de todas as vantagens que a OO pode trazer

ao desenvolvimento de software, um problema
fundamental ainda persiste:
A identificao correta e completa dos objetos

(classes), atributos e operaes.

Diagrama de Classes
Anlise (continuao)
Vrias tcnicas (de uso no exclusivo) so usadas para identificar

classes:
Categorias de Conceitos;
Anlise Textual de Abbott (Abbot Textual Analysis);
Anlise de Casos de Uso:

Categorizao BCE.
Padres de Anlise (Analisys Patterns);
Identificao Dirigida a Responsabilidades.

Diagrama de Classes
Anlise dos casos de uso: processo
Diagrama de Classes
Processo a ser realizado
Tcnica preconizada pelo Processo Unificado;
O MDC utilizado como pronto de partida:
Premissa: um caso de uso corresponde a um comportamento

especfico do software. Esse comportamento somente pode
ser produzido por objetos que compem o sistema;
Portanto, a realizao de um caso de uso

responsabilidade de um conjunto de objetos que devem
colaborar para produzir o resultado do caso de uso em
questo.
Diagrama de Classes
Processo a ser realizado (continuao)
O MDC utilizado como pronto de partida (continuao):
Diante desta realidade, o modelador aplica a tcnica de

anlise dos casos de uso
Com o objetivo de : identificar as classes necessrias

produo do comportamento que est documentado na
descrio do caso de uso (quem este sujeito?).

Diagrama de Classes
Procedimento de aplicao:
1) O modelador estuda a descrio textual de cada caso de

uso para identificar classes candidatas;
2) Para cada caso de uso, se texto (fluxos principal, alternativos

e de exceo, ps-condies e pr-condies, etc.) analisado;
3) Na anlise de certo caso de uso, o modelador tenta identificar

classes que possam fornecer o comportamento do mesmo.

Diagrama de Classes
Procedimento de aplicao (continuao):
4) Na medida em que os casos de uso so analisados um a

um, as classes do software orientado a objetos so
identificadas;
5) Quando todos os casos de uso tiverem sido analisados,

todas as classes (ou pelo menos a maioria delas) tero sido
identificadas.
Este procedimento pode ser aplicado com uso da categorizao

BCE.

Diagrama de Classes
Categorizao BCE
Diagrama de Classes
Categorizao BCE
Como o nome diz uma categorizao;
Quando categorizamos alguma coisa, o que fazemos

usualmente?
Na categorizao BCE, os objetos de um sistema orientado a

objetos so agrupados de acordo com o tipo de
responsabilidade eles atribuda.

Diagrama de Classes
Categorizao BCE (continuao)
Na categorizao BCE, os objetos de um sistema

orientado a objetos so agrupados:
Objetos de entidade (Entity): usualmente objetos do domnio

do problema;
Objetos de fronteira (Boundary): atores interagem com

esses objetos;
Objetos de controle (Control): servem como intermedirios

entre Boundaries e de Entities, definindo o comportamento
de um caso de uso especfico.

Diagrama de Classes
Categorizao BCE: entidade
Diagrama de Classes
Objetos de entidade (Entity): usualmente objetos do

domnio do problema:
Repositrio para informaes e as regras de negcio

manipuladas pelo sistema:
Representam conceitos do domnio do negcio.

Diagrama de Classes
Objetos de entidade (Entity): usualmente objetos do domnio

do problema (continuao):
Caractersticas:
Normalmente armazenam informaes persistentes

(estado);
Vrias instncias da mesma entidade existindo no

sistema;
Participam de vrios casos de uso e tm ciclo de vida

longo.
Diagrama de Classes
Objetos de entidade (Entity): usualmente objetos do

domnio do problema (continuao):
Exemplo:
Um objeto Pedido participa dos casos de uso

Realizar Pedido e Atualizar Estoque. Este objeto
pode existir por diversos anos ou mesmo tanto
quanto o prprio sistema.

Diagrama de Classes
Categorizao BCE: fronteira
Diagrama de Classes
Objetos de fronteira (Boundary): atores interagem com esses

objetos:
Realizam a comunicao do sistema com os atores:
Traduzem os eventos gerados por um ator em eventos

relevantes ao sistema: eventos de sistema;
Tambm so responsveis por apresentar os resultados de

uma interao dos objetos em algo inteligvel pelo ator.
Existem para que o sistema se comunique com o mundo

exterior:
Por conseqncia, so altamente dependentes do ambiente.

Diagrama de Classes
Objetos de fronteira (Boundary): atores interagem com

esses objetos (continuao):
H dois tipos principais de objetos de fronteira:
Os que se comunicam com o usurio (atores

humanos): relatrios, pginas HTML, interfaces
grfica desktop, etc;
Os que se comunicam com atores no-humanos

(outros sistemas ou dispositivos): protocolos de
comunicao.
Diagrama de Classes
Categorizao BCE: controle
Diagrama de Classes
Objetos de controle (Control): so a ponte de comunicao entre

objetos de fronteira e objetos de entidade;
Responsveis por controlar a lgica de execuo correspondente a

um caso de uso;
Decidem o que o sistema deve fazer quando um evento de sistema

ocorre:
Eles realizam o controle do processamento;
Agem como gerentes (coordenadores, controladores) dos outros

objetos para a realizao de um caso de uso.

Diagrama de Classes
Objetos de controle (Control, continuao):
Traduzem eventos de sistema em operaes que devem

ser realizadas pelos demais objetos.

Diagrama de Classes
Padro MVC: viso geral
Diagrama de Classes
Padro MVC
MVC (Model, View, and Controller) um padro de

arquitetura de software;
No contexto da engenharia de software, um padro uma

soluo comprovada a um problema recorrente;
Padres especificam abstraes que esto acima do nvel de

classes, objetos isolados ou de componentes.

Diagrama de Classes
Padro MVC (continuao)
As vantagens ao se utilizar padres de projeto so:
Ter um vocabulrio comum para a discusso de problemas e

solues de projeto;
Facilitar documentao e manuteno da arquitetura do

software;
Auxiliar o projeto de uma arquitetura com determinadas

propriedades.

Diagrama de Classes
A ideia do padro MVC desacoplar ao mximo a apresentao

da aplicao (view) da lgica do negcio (business model);
Muitos sistemas tornam-se complexos, pois misturam cdigo da

apresentao com o cdigo da lgica do negcio:
Qualquer mudana requerida pelo usurio na forma de

apresentao das informaes exige tambm mudana na
lgica do negcio.
A camada de apresentao envolve interfaces e tambm

relatrios.

Diagrama de Classes
Frequente a utilizao de diversas interfaces para um mesmo

negcio em funo do tipo de usurio ou do tipo de dispositivo
de sada;
Se para cada tipo de usurio/tipo de dispositivo de sada fizermos

uma lgica de negcio diferente, estaremos replicando cdigo
desnecessariamente:
Por exemplo, uma aplicao que mostra o extrato bancrio de

uma conta corrente em diversos tipos de dispositivo tais
como PC, caixa automtico, Palm e celular.

Diagrama de Classes
A lgica do negcio sempre a mesma, juntar as transaes

executadas em uma conta em um perodo, mudando
apenas a forma de mostrar os dados.

Diagrama de Classes
Padro MVC: conceitos
Diagrama de Classes
O padro MVC prope a diviso da aplicao em trs
partes (ou camadas):
Modelo do negcio (model): contm os dados do negcio e as

regras do negcio que ditam o acesso e a modificao dos dados.
De forma mais prtica, encapsula os dados e os
comportamentos do negcio e salva os mesmos sem se preocupar
em como sero mostrados.
Viso (view): responsvel pela interao com o usurio e por

apresentar as diversas vises que dos dados do negcio. No se
preocupa em como os dados foram obtidos, apenas em
apresent-los.

Diagrama de Classes
O padro MVC prope a diviso da aplicao em trs
partes (ou camadas):
Controle (controller): comanda o fluxo de obteno,

encaminhamento e apresentao das informaes fazendo a
intermediao entre as camadas de viso e de modelo.

Diagrama de Classes
H duas formas bsicas:
Na primeira (a)os eventos/respostas da interface so tratados

diretamente pela camada de viso (view);
Na segunda, pelo controle que ento seleciona a viso

apropriada.
O controle interpreta os eventos e informaes fornecidas pelo

usurio e chama as aes que podero mudar o estado do
modelo do negcio.
Diagrama de Classes
Exemplo
Requests
Respostas
Controller
Envio
Requisio
Dados View
retorno
Model
Separao do cdigo em trs camadas
Diagrama de Classes
As alteraes do modelo so retratadas pela camada da viso

podendo ter o controle como intermedirio ou no;
H um controlador para cada caso de uso do modelo do

negcio.

Diagrama de Classes
Item

Diagrama de Classes
O modelo MVC bastante utilizado em aplicaes WEB;
Um servio pode ser chamado a partir de diferentes clientes tais

como: celulares, PCs e Tablets;
A lgica do negcio, no entanto, permanece a mesma

independente do cliente;
Nas aplicaes WEB o servidor escolhe a viso mais

apropriada, sendo que os servidores no so
necessariamente mquinas distintas.
Diagrama de Classes
Existe um framework chamado JSF que diminui o esforo de

desenvolver uma aplicao Web segundo o padro MVC:
Framework uma coleo de interfaces e classes para

auxiliar o desenvolvimento e manuteno de aplicaes.

Diagrama de Classes
Padro MVC e o Observer
Diagrama de Classes
Padro Observer
O objetivo do padro observer reduzir o acoplamento

entre classes;
Podemos utilizar este padro em conjunto com o MVC para

desacoplar as classes da camada de viso das do
modelo;
Este o desacoplamento mais importante, pois separar as

classes de controle das de viso nem sempre uma tarefa
evidente.
Diagrama de Classes
Padro Observer (continuao)
Suponha que os dados do modelo devem ser vistos de vrias

maneiras (por meio de diferentes interfaces), mas de
maneira sincronizada, ou seja, cada mudana nos dados do
modelo deve ser refletida igualmente em todas as
interfaces;
Neste caso o padro observer til, pois as classes do

modelo no necessitam saber quantas e quais classes da
camada de viso dependem delas.

Diagrama de Classes
Padro Observer (continuao)
til nas situaes seguintes:
Quando uma modificao em um objeto implica

modificaes em outros e no se sabe quantos objetos
precisam ser modificados;
Quando um objeto deve ser capaz de notificar outros objetos,

mas sem pressupostos sobre os objetos a serem notificados.

Dvidas?
edmodo.com ou anderson.siqueira@fmu.br
Referncias
Referncias
BLAHA, M.; RUMBAUGH, J. Modelagem e Projetos baseados
em Objetos com UML 2. 2a. ed. Rio de Janeiro: Elsevier, 2006.
496p.
BEZERRA, E. Princpios de Anlise e Projeto de Sistemas

com UML. 3. ed. Rio de Janeiro: Campus, 2015. 398p.

08asemana ModSist Prof Anderson Siqueira PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

08asemana ModSist Prof Anderson Siqueira PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Anlise e Desenvolvimento de

Prof Anderson Siqueira

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 3

Dois princpios de projeto, dentre outros so: acoplamento e a

A coeso uma medida do quo fortemente relacionadas e

extremamente importante assegurar que as

Em outras palavras, o projetista deve definir classes de tal

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 5

Na prtica o indcio de que uma classe tem baixa coeso:

Apresentar dois ou mais grupos de atributos semelhantes

Contudo atributos diferentes ENTRE os grupos;

O mesmo ocorre com os mtodos.

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 6

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 7

O acoplamento uma medida de quo fortemente uma

Uma classe com acoplamento fraco (baixo) no depende

Por outro lado, uma classe com acoplamento forte

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 8

Exemplo de ALTO e BAIXO acoplamento:

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 9

Alm disso, uma classe com alto acoplamento mais

PORTANTO criar modelos com alta coeso e baixo

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 10

Eventos de sistema correspondem s aes do ator no cenrio de

Sendo assim, relativamente fcil identificar eventos de sistemas

No caso particular em que o ator um ser humano e existe uma

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 12

Crditos: Srgio Furgeri, disponvel em http://www.sergio.pro.br/trabalhos/46_delphi_manipulacao_de_listbox_combobox_e_imagens.pdf

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 14

Crditos: Srgio Furgeri, disponvel em http://www.sergio.pro.br/trabalhos/46_delphi_manipulacao_de_listbox_combobox_e_imagens.pdf

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 15

Considere o formulrio a seguir, para o caso de uso (do SCA)

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 16

No formulrio anterior, temos a seguinte lista de eventos de

Solicitao de validao de matrcula de professor;

Solicitao de adio de uma disciplina grade;

Solicitao de adio de um item de disponibilidade (dia,

Solicitao de registro da grade.

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 17

Apesar de todas as vantagens que a OO pode trazer

A identificao correta e completa dos objetos

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 19

Vrias tcnicas (de uso no exclusivo) so usadas para identificar

Anlise Textual de Abbott (Abbot Textual Analysis);

Anlise de Casos de Uso:

Padres de Anlise (Analisys Patterns);

Identificao Dirigida a Responsabilidades.

Tcnica preconizada pelo Processo Unificado;

O MDC utilizado como pronto de partida:

Premissa: um caso de uso corresponde a um comportamento

Portanto, a realizao de um caso de uso

O MDC utilizado como pronto de partida (continuao):

Diante desta realidade, o modelador aplica a tcnica de

Com o objetivo de : identificar as classes necessrias

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 23

1) O modelador estuda a descrio textual de cada caso de

2) Para cada caso de uso, se texto (fluxos principal, alternativos

3) Na anlise de certo caso de uso, o modelador tenta identificar

Prof Anderson Siqueira 8 Semana - Abril / 2017.1 24

Procedimento de aplicao (continuao):

4) Na medida em que os casos de uso so analisados um a

5) Quando todos os casos de uso tiverem sido analisados,

Este procedimento pode ser aplicado com uso da categorizao