Análise do Sistema

Alexandre Mota(acm@cin.ufpe.br)

Desenvolvendo o Sistema

Documentode

Requisitos

...

Problema Solução

: EstudanteForm. Matrícula

1: entra id

2: verifica id

3: entra semestre atual4: cria novo cronograma

5: processa

Modelo dosrequisitos

Perspectiva do Usuário

Detalhes eDec. de projeto

Perspectiva do Desenvolvedor

Sub-sistemas

Modelo UML: “Visão 4+1”

Development View

Process View Physical View

Use Cases/Scenarios

Logical View

Class diagrams,Sequence diagrams Component diagrams

Deployment diagrams Deployment diagrams

Use Case diagrams,Sequence diagrams

Funcionalidade

Performance

Configuração

Topologia

Modelo

Para criarmos um modelo do sistema, temos que identificar: Objetos Classes

Atributos Métodos

Associações entre classes Outros relacionamentos entre classes

Classes

<< Estereótipo >>NomeDaClasse

+ atribPub: Tipo = Inicial# atribProt- atribPriv<< constructor>>new()<<query>>getRiscos(o: Cliente)

** pode ser:{persistent}

Semântica das Classes

A descrição da classe deve Focar em seu propósito

(funcionalidade) e não em sua implementação

Na análise, as classes só devem estar relacionadas ao domínio do problemaEssência é “O QUÊ” e não “COMO”Essência é “O QUÊ” e não “COMO”

Análise Projeto

Abordagem 1: Linguagem Para identificar objetos, classes e interfaces,

liste todos os nomes (substantivos), pronomes e frases do seu documento de requisitos/casos de uso

Nomes próprios e frases que indiquem unicidade representam objetos João, ela, minha conta, o elevador 1

Nomes comuns ou no plural indicam classes ou interfaces Clientes, contas, um elevador

Abordagem 1: Linguagem

Para identificar serviços (métodos), atente para os verbos ou frases verbais Clientes podem depositar na poupança

Para identificar atributos, analise as frases que expressam propriedades de objetos/classes Clientes possuem uma senha, ou

A senha do cliente deve ser de no mínimo 8 caracteres

Abordagem 1: Linguagem

Verbos também podem identificar associações entre objetos, classes ou interfaces Uma disciplina tem pelo menos 3 alunos

matriculados Assim como, relacionamentos de

herança, dependência, etc. Uma poupança é um tipo especial de

conta bancária

Infelizmente...

Na documentação informal, existirão nomes que não serão objetos, classes e nem interfaces

Não há um algoritmo que nos permita modelar um sistema da forma perfeita

Tudo depende de experiência e julgamentos corretos na hora de escolher o grau de abstração certo

Utilidade dos casos de uso Casos de uso são mais interessantes que

texto informal pois são mais estruturados e orientados a serviços

Casos de uso naturalmente são vistos como métodos

As intenções de um subconjunto de casos de uso revelam as classes

Demais elementos são obtidos pelos fluxos de ações ou diag. de seqüência

Diagrama de Seqüências

Gerente BDSistemaAbre Conta

Solicita Info Cliente

Info Cliente Fornecida

Solicita Tipo de Conta

Tipo de Conta Fornecida

Solicita Saldo Inicial

Saldo Inicial Fornecido

ConfirmaçãoCria Conta

Abordagem 2: Cartões CRC CRC vem de Class-Responsibility-

Collaboration Um cartão CRC mostra

Nome da classe e descrição Suas responsabilidades

Conhecimento interno (atributos) Seus serviços (métodos)

Os colaboradores das responsabilidades Um colaborador é uma classe cujos serviços são

necessitados por uma responsabilidade

Uma sessão CRC

Grupo de pessoas desenvolvem um cenário

Um cartão é criado para cada objeto no cenário

Cada participante é associado a grupo de cartões A pessoa torna-se a “classe”

Uma sessão CRC

Os cenários definidos são praticados pelos participantes

Os cartões são anotados com as responsabilidades e colaborações

Novos cartões surgem para novos objetos descobertos

Exemplo de CRC

Class Name Catalog

Responsibilities Collaborations

Catalog number

Remove Book

Add Book

Book

Catalog store{{

Atributos

Métodos

AtualizaçõesClass Name Catalog

Responsibilities Collaborations

Catalog number

Remove Book

Add Book

Book

Catalog store

Diagrama de Classes + Diagrama de Seqüências

{{

Atributos

Métodos

Evolução

Trabalho vai bem se . . . Todas as classes têm nomes

significativos, domínio específico e pequeno conjunto de colaboradores

Não há classes “instáveis” (uma classe que colabora com alguém precisa ser re-definida completamente)

Mudança nos requisitos só envolve classes

Evolução

E mal se . . . Várias classes não têm

responsabilidades Mesma responsabilidade atribuída a

várias classes Todas as classes colaboram com

todas as outras classes

Estereótipos (<< >>)

Um estereótipo representa a classificação de uma classe

Toda classe deve ter apenas um estereótipo

Mais comuns Boundary, Entity, Control, Exception,

Utility

Boundary Classe boundary modela a comunicação

entre a parte interna e externa do sistema

Mais comuns Windows (GUI) Protocolo de comunicação (interface do

sistema) Interface com a impressora Sensores Class Name

<<boundary>>

Boundary Informações entre ator e sistema

devem estar contidas em classe boundary Diagramas de seqüência são

examinados para identificar o conteúdo da classe : Estudante

Form. Matrícula

1: entra id

2: verifica id

3: entra semestre atual

4: cria novo cronograma

5: processa

Form. Matrícula<<boundary>>

Janelas Protótipos (desenhos) de janelas

podem ser criados para representar a classe boundary ao usuário

Interface com outros Sistemas

Classe boundary também pode ser usada para modelar interface com outros sistemas

Suas características são: Informação a ser comunicada com o

outro sistema Protocolo de comunicação usado

nesta transferência

Entidade Classe de entidade modela informação

geralmente “persistente” Valores de seus atributos são

freqüentemente fornecidos por um ator Exemplos seriam

Curso Estudante Professor Conta

Conta<<entity>>

Diagrama de Seqüência

Os diagramas de seqüência são atualizados Classes adicionais são incluídas no

diagrama Objetos no diagrama são associados a

classes

Diagrama Atualizado

John : Student

:Registration Form

:Catalogue :Course :Student Record

:Course Roster

:Schedule :BillingSystem

:Registration Manager

:Schedule Form

1: enter id2: validate id

3: enter current

4: create new 5: display

6: display

7: select course

8: process

16: registration complete

9: create schedule

10: get prerequisite

11: prerequisite taken ?

12: add student (John)

15: registration complete

13: print

14: send to billing system

Bibliografia

Sommerville, I. Software Engineering

Kruchten, P. The Rational Unified Process: An Introduction

Tepfenhart, W. et al. Practical Object-Oriented Development with UML and Java