Elaboração Projeto Final - APGS Adriana P. de Medeiros

Elaboração

Projeto Final - APGS

Adriana P. de Medeiros

2Análise, Projeto e Gerência de Sistemas Projeto Final

Elaboração

Objetivo da fase Análise e Projeto

Modelo Conceitual

Modelo de Projeto

Diagramas de Sequência

Diagrama de Estados

Proposta de componentes

Documentação


Objetivo

Analisar o domínio do problema e estabelecer uma base arquitetural para o novo sistema

Necessário:

concluir os casos de uso de sistema construir o modelo conceitual construir o modelo de projeto construir os diagramas de sequência construir diagramas de estados (se necessário) preparar proposta de componentes para o sistema


Análise e Projeto

Elaboração


UML: Perspectivas Múltiplas

A UML descreve tipos puros de diagramas Diagrama de Classes, Diagrama de Sequência, etc.

A mesma notação diagramática pode ser usada em três tipos de perspectivas e modelos:

Perspectiva essencial ou conceitual

Diagramas representam uma descrição de coisas no mundo real ou domínio de interesse

Perspectiva de especificação

Diagramas representam uma descrição de abstrações de software ou componentes com especificações e interfaces

Perspectiva de implementação Diagramas representam uma descrição de implementação de software

em uma tecnologia e linguagem específica (como Java)


Diagrama de Classes: Perspectivas

Conceitual

Especificação (Tipos e Interfaces)

Implementação

Modelo Conceitual

Modelo de Projeto


Modelo Conceitual

Ilustra as classes conceituais significativas em um domínio de problema

Pode mostrar: objetos do domínio ou classes conceituais

associações entre as classes conceituais

atributos de classes conceituais

Usando a notação UML, um modelo conceitual é ilustrado como um conjunto de diagramas de

classes, nos quais não se definem operações


Modelo Conceitual

Um Modelo Conceitual é uma representação de classes conceituais do

mundo real, não de componentes de software.

Durante a Modelagem Conceitual levantamos conceitos relativos

ao domínio de um problema. Devemos nos concentrar no negócio e não em detalhes de

implementação.


Modelo Conceitual

Modelos não são corretos ou incorretos; eles são mais

úteis ou menos úteis [Fowler 97]

Se modelamos um conceito de uma determinada

maneira, devemos nos questionar quanto a sua utilidade

e se a forma que modelamos é a que mais nos facilitará.

Queremos:

Representar abstrações

Independência de implementações

Facilidade de comunicação

[Fowler 97] Fowler, M., Analysis Patterns – Reusable Object Models, Addison Wesley, 1997


Pedido

nomeidade

Funcionário

LinhaDeItemDePedidoquantidade

Organização

Cargo

Produto

CD DVD Livro

1

1..*

{incompleto}

1*

*

Exemplo: Modelo Conceitual

númerodata

preenche

11

1


Dicas

Se você não pensar em uma classe conceitual X como um número ou um texto no mundo real, então X provavelmente será uma classe conceitual, não um atributo

Concentre-se nas associações cujo conhecimento do relacionamento deve ser preservado por algum tempo (associações “que devem ser conhecidas”)

Relacione classes conceituais com uma associação, não com um atributo

Fonte: Livro “Utilizando UML e Padrões” - Craig Larman


Modelo de Projeto

Contém diversos tipos de diagramas, incluindo os diagramas de classes, de pacotes e de interação

Um diagrama de classe de projeto ilustra as especificações para classes de software e interfaces em uma aplicação. Inclui:

classes, associações e atributos

informação de tipo de atributo

métodos

interfaces, com suas operações e constantes

navegabilidade

dependências


Modelo de Projeto

Considerar:

Classes AbstratasInterfaces

Padrões de Projeto

Visibilidade de Atributos e Operações

Operações necessárias

Restrições

Pacotes

Diagramas de Sequência Diagramas de Estados

Classes de Projeto


Pedido

1

Exemplo: Modelo de Projeto

número: Integerdata: Date

criarLinhaDeItem(...)obterTotal ()

LinhaDeItemDePedido

quantidade: Integer

obterSubTotal ()

contém 1..*

EspecificaçãoProduto

descricao: Stringpreco: Moeda

...

descreve

1

*


Revisão: Classes Abstratas

Não podem ser instanciadas

São usadas quando não conhecemos a implementação de seus métodos

A implementação é dada por suas subclasses


Exemplo

base x altura base x altura/2PI x raio x raio

calcularArea()

alturabase

calcularArea()

Retânguloalturabase

calcularArea()

Triânguloraio

calcularArea()

Círculo

Figura


Revisão: Interfaces

Uma interface é uma coleção de operações usadas para especificar um serviço de uma classe ou componente

Interfaces permitem separar a especificação de funcionalidade, em termos de operações, de sua implementação em termos de método

Esta separação torna o cliente que usa uma interface independente da implementação desta interface

Uma implementação particular de uma interface, como por exemplo

uma classe ou componente, pode ser substituída por uma outra

implementação sem que seja necessário mudar o cliente


Exemplo

Cliente

Transacao

<<interface>> Transacao

retirarDinheiro()depositarDinheiro()

Conta

create()obterNumero()retirarDinheiro()depositarDinheiro()

numero:Integer<<usa>>

Cliente<<usa>>

Conta

create()obterNumero()retirarDinheiro()depositarDinheiro()

numero:Integer

OU


Revisão: Pacotes

Mecanismo de propósito geral para organizar elementos de um modelo em grupos

Cliente

FormPedidoPedidoRegras de Negócio

+ Window+ Form# EventHandler

GUI Cliente

FormPedido

Pedido


Revisão: Generalização de Pacotes

+ Windows+ Form# EventHandler

GUI

WindowsGUI

+ GUI::Window+ Form# GUI::EventHandler+ VBForm

MacGUI


Revisão: Subsistemas

Um subsistema é simplesmente uma parte de um sistema e é usado para decompor um sistema complexo em partes “quase” independentes

Sistema de Varejo

Gestão da LojaAtendimento ao cliente

Controle de Estoque


Revisão: Padrões de Projeto

São descrições de objetos e classes comunicantes que são customizados para resolver um problema geral de projeto num contexto particular

São classificados por dois critérios: Finalidade – o que o padrão faz

Criação

Estrutural

Comportamental

Escopo – especifica se o padrão se aplica a

Classes

Objetos


Revisão: Padrões de Projeto

Analisar o uso de padrões de projeto para modelar problemas já conhecidos

Criação

Singleton, Factory Method, Abstract Factory, etc

Estrutural

Composite, Decorator, Façade, etc

Comportamental

Command, Observer, State, Strategy, etc

O uso dos padrões deve ser justificado


Diagrama de Sequência

Diagramas de Sequência apresentam a interação entre um grupo de objetos de um sistema, através de mensagens ou controles, em um determinado cenário

Servem para modelar o “funcionamento” do sistema, inclusive a concorrência entre objetos

Enfatizam a ordem temporal das mensagens

Úteis para compreensão da dinâmica, principalmente para iniciantes na OO


Diagramas de Sequência são primariamente utilizados para a atribuição de responsabilidades a cada um dos objetos do sistema - operações

Além de servir para descoberta das operações, serve para a modelagem da interação entre os objetos

Completam o tripé da análise: Casos de Uso - comportamento externo (funcional)

Diagramas de Classes - visão estática

Diagramas de Sequência - visão dinâmica

Aplicação

Internos


Cada Caso de Uso provê vários cenários

Um cenário é uma instância de um caso de uso

O Diagrama de Classes mostra os objetos da aplicação

Fazemos um Diagrama de Sequência mostrando a interação dos objetos em um determinado cenário, ou seja, para cada cenário de um Caso de Uso teremos um diagrama

Construção


Construção (cont.)

Diagrama de Classes

MeioTransporte

Carro Navio...

Caso de Uso

Nome: Reservando PassagemAtores: AgenteCurso de Eventos

1- Ujfsaj jfklsdj jfdkkj fl als ;a f a;2- jfaskdjf lj kl;k kdfjasdkl lkssss3- jsdkfklk lkkkk lopjfa[ pokfsao opw4- skdjfI)kkk;’PIO lkkfapp kjadfp 5- lkLKO oeppae fokkzp;xp pokf ;lp[

Alternativas 1- Ijfksa kJFKJ a;lkj ;kjfklasojk;a

Diagrama de Sequência

Janela de Entrada de

Pedidoum Pedido

uma linhade

Pedido

um itemem Estoque

um Item deEntrega

um Item deRefabricação

criar()

* criar()

verifica ()

[verfifica = true]retirar_item()

refabricar_item()

[refabricar_item = true]new

[verfifica = true]newObjetos Cenário

Interação

Operações


Exemplo

Janela de Entrada de

Pedido

:Pedido

:linha_Pedido

:Item_Estoque

:Item_Entrega

:Item_Refabricação

criar()

* criar()

verificar ()

[verfifica = true]retirar_item()

refabricar_item()

[refabricar_item = true]

[verificar = true]criar ()

criar ()

AtendenteInforma dados

data_entrega


Exemplo

: Registro: CatálogoProduto

: ListaEspecificações : Venda li :LinhaDeItem

criar(esp, qtd)

criarLinhaDeItem (esp, qtd)

entrarItem(id, qtd)

obterEspec(id)buscarEspec(id)

: ListaItensDeVenda

adicionar(li)


Diagrama de Estados

Mostra as sequências de estados que um objeto ou uma interação assume em sua vida, em resposta a estímulos recebidos, juntamente com suas respostas e ações

Complementa a classe e relaciona os possíveis estados que os objetos da classe podem ter e quais eventos podem causar a mudança de estado (transição)


Registrando pedido Alterando pedido Cancelando pedido

Analisando pedido Aprovando pedido

Colocando pedidoem pendência

Atendendo pedido

Pedido enviado Alteração de pedido solicitada

Cancelamento de pedido solicitado

Pedido para análise requisitado Pedido será

cancelado

Pedidocancelado

Pedido p/aprovação

Pedido será atendidoPedidoatendido

Pedido já podeser atendido

Pedido não pode seratendido no momento

Exemplo


Proposta de Componentes

Propor componentes para o novo sistema

Especificar as classes para cada componente

Definir as interfaces de cada componente Especificar as operações de cada interface (incluindo a

assinatura de cada operação)

apenas componentes considerados necessários pelo grupo

A proposta deve ser justificada


Referências

1. The Unified Modeling Language User Guide By Booch, Grady /

Rumbaugh, Jim / Jacobson, Ivar; ISBN 0201571684.

2. Understanding UML: The Developer's Guide, Harmon, Paul / Watson,

Mark; ISBN 1558604650.

3. Utilizando UML e Padrões: Larman, Craig; ISBN 8536303581

4. Padrões de Projeto: Soluções Reutilizáveis de Software Orientado a

Objetos, Gamma, Erich / Helm, Richard / Johnson, Ralph / Vlissides,

John; ISBN 8573076100

5. http://hillside.net/patterns/


Documentação Gerada

Introdução Apresentação da empresa (o cliente) Objetivos gerais do projeto Estrutura do documento

Modelagem de Negócio Características da empresa (descrição, estrutura organizacional, recursos de informática, expectativa do cliente e processo atual ) Processos de negócio (Casos de uso de negócio) Problemas identificados Necessidades detectadas

Requisitos Diagrama de Casos de Uso e descrições Requisitos Suplementares

Alternativas de Solução Descrição de cada alternativa Análise comparativa das alternativas Alternativa recomendada pela equipe Alternativa escolhida pelo usuário e critério de escolha


Documentação Gerada Análise e Projeto

Modelo Conceitual (diagrama de classes conceituais) Modelo de Projeto

- Diagrama de Classes de Projeto• tipos de atributos e operações

• classes abstratas e interfaces

• padrões de projeto

• pacotes, etc. - Justificativa para o uso de Padrões de Projeto- Diagramas de Sequência

• apenas para os casos de uso de sistema principais

- Diagrama de Estados (se necessário)

- Proposta de Componentes

Glossário Anexos

Documents

Elaboração Projeto Final - APGS Adriana P. de Medeiros