RESUMO ANALISE UHLT

2009-2010

FREQUENCIA II
R.U.P  Rational Unified Process

È uma metodologia de desenvolvimento, baseia-se numa

arquitectura de componentes sendo vocacionado para projectos de
negócios electrónicos.

Características:

 è uma metodologia de desenvolvimento interactiva

 Propõe a gestão integrada de requisitos desde a sua

identificação até á implementação.

 Propõe o desenvolvimento baseado em arquitecturas de

software e de componentes.

 Defende a modelação visual

 Defende o controlo de qualidade permanente

 Orientado para “use cases”

Características:

 Todos os modelos construídos ao longo das diversas tarefas do

R.U.P são elaborados a partir do modelo de casos de utilização
produzido durante a tarefa de levantamento de requisitos.

 Os casos de uso baseiam-se na arquitectura de software

Arquitectura 4+1
UML  Unified Modelling Language

È uma linguagem cujos objectivos são:

♦ Especificação
♦ Construção
♦ Visualização
♦ Documentação de um sistema de informação

Esta linguagem é independente do domínio de aplicação,

independente do processo de desenvolvimento e independente
das ferramentas de modelação

Elementos Básicos:

⇒ Classe
⇒ Interface
⇒ Nó
⇒ Use cases
⇒ Actor
⇒ Componente

Relações Standard:

⇒ Associação
⇒ Realização
⇒ Transição de estado
⇒ Dependência
⇒ Generalização

Tipos Diagrama:

⇒ Diagrama de casos de uso

⇒ Diagrama de classes e de objectos

⇒ Diagramas de comportamento
o Estados
o Actividades
o Interacção: Sequencias e colaboração

⇒ Diagramas de Arquitectura
o Diagramas de componentes
o Diagramas de Instalação
Diagrama de casos de uso  Representam a visão do sistema na
perspectiva do utilizador

Diagrama de classes  Permitem especificar a estrutura

estática de um sistema de forma orientada a objectos.

Diagrama de comportamento  Permitem especificar o

comportamento de um sistema de forma orientada a objectos.

Diagrama de Arquitectura  Dão a visão da disposição dos

componentes físicos de um sistema.

Mecanismos comuns:

⇒ Anotações (ilustra um comentário sem ter qualquer valor

semântico)

⇒ Extensões(adicionam entendimento ao desenho, devem usar

referencias)

⇒ Localização(devem ser colocadas perto dos elementos a que

dizem respeito)

⇒ Visibilidade (Dependendo da ferramenta podem ser visíveis ou

invisíveis)

⇒ Evolução (devem permanecer no desenho enquanto “fazem

falta”)

USE CASES:

Características:

Definição  ”sequencia de acções que um ou mais actores

realizam num sistema de modo a obterem um resultado particular”

Requisito  Especificação de uma determinada acção ou condição

que o sistema deve satisfazer.

Requisito Funcional acção do sistema (ex: consulta de catálogo

de serviços)

Requisito não funcional  Aspecto geral do sistema (ex:

desempenho)
Diagramas de use cases:

⇒ Permitem a representação de requisitos funcionais

⇒ Suportados sempre na visão do utilizador
⇒ Facilitam a comunicação e a gestão do projecto
⇒ Apresentação oval
⇒ Organização graficamente visível
⇒ Detalhe dependente do projecto, do cliente e do sistema

Cenário:

⇒ Sequencias de acções em texto que ilustram um

comportamento do sistema.

⇒ Descrição estruturada que pode incluir pré-condiçoes e/ou

Pós-condições.

Relações:

⇒ Generalizações
⇒ Inclusão, os includes ou uses são as pré condições
⇒ Extensão - Extends

Modelação de Estrutura:

Introdução:

⇒ Consiste na identificação de classes e as suas respectivas

relações.
⇒ Uma classe consiste numa estrutura que permite criar
objectos semelhantes, apresentam estado e comportamento
semelhantes.
⇒ Um objecto é uma entidade do mundo real e apresenta um
estado e comportamento próprios.
⇒ Os objectos inter-actuam entre si por troca de mensagem.

Neste sentido diz-se que uma classe é uma fábrica de objectos e

que um objecto é uma instancia de uma classe.

Classe:

⇒ Descrição de um conjunto de objectos que partilham os

mesmos atributos, operações, relações e a mesma
semântica.
 ⇒ Uma classe corresponde a algo tangível ou a uma
abstracção conceptual existente no domínio do engenheiro
de software.

⇒ È simples e facilmente entendida

⇒ Providencia uma abstracção definida a partir do domínio do

problema ou do domínio da solução.

⇒ Junta um conjunto restrito e bem definido de

responsabilidades.

⇒ Providencia um separação clara entre a especificação

abstracta e a sua implementação.

Uma classe tem três partes:

o Nome
o Atributos
o Operações

Os atributos podem ser:

Públicos (+=>): qualquer classe tem acesso.

Privados (-=>): só a própria classe tem acesso.
Protegidos (#=>): Qualquer descendente tem acesso.

As relações podem ser de três tipos: Dependências,

Generalizações e Associações.

Dependência :

Indica que a alteração na especificação de uma elemento pode

afectar outro elemento que a usa, mas o oposto não é
necessariamente verdade.

Generalização => Herança de classes :

Relação entre um elemento geral (ex: superclasse) com um

elemento mais especifico (ex: subclasse)

Associação :

Relação estrutural que especifica que objectos de uma classe estão

ligados a objectos de outra.
 ⇒ Agregação

Traduz apenas o facto de uma classe ser composta por diferentes

outras classes que são suas componentes.

Interfaces: especificações de métodos

⇒ Dão a conhecer um determinado elemento, escondendo os

seus detalhes internos.

⇒ É realizada (ou implementada) por uma ou mais classes, as

quais prometem implementar todos os métodos nela
especificados.

Benefícios Programação:

⇒ captura de semelhanças entre classes não relacionadas

sem forçar a criação de relações artificiais entre elas.

⇒ Declaração de métodos que uma ou mais classes esperam

implementar.

⇒ Revelar a interface de programação de um objecto sem

revelar a sua classe.

Relações com classes e componentes:

⇒ Generalização
⇒ Associação
⇒ Dependência
⇒ Realização

Instancias e/ou Objectos:

Definição:

Manifestação concreta de uma abstracção, á qual um conjunto de

operações pode ser aplicado, e que tem um estado que regista os
efeitos das operações realizadas.
Definição Instância:

Manifestação concreta de uma abstracção, à qual um conjunto de

operações pode ser aplicado, e que tem um estado que regista os
efeitos das operações realizadas.

Definição Objecto:

Instancia de uma classe, herdando, por consequência todos os

atributos e métodos definidos na própria classe e possuindo uma
representação de execução própria, a qual se pode designar
genericamente por estado.

Diagrama de classes:

Ilustra um conjunto de classes, interfaces, colaborações e

respectivas relações , em geral de dependência, generalização e de
associação.

Os diagramas de classe são usados quando:

⇒ Queremos modelar o vocabulário de um sistema.

⇒ Queremos modelar colaborações Simples.

⇒ Queremos modelar o desenho de um simples esquema de

uma base de dados.

Diagrama de objectos:

Ilustra um conjunto de objectos e respectivas relações num

determinado momento.

Características:

⇒ Permite captar uma imagem momentânea sobre determinado

sistema.

⇒ È um grafo composto por objectos e ligações entre eles.

⇒ Não pode especificar completamente a estrutura de objectos

de um dado sistema.
Modelação de comportamento:

Comportamento inter-objectos:

⇒ Troca de mensagens entre objectos por diagramas de

interacção.

⇒ Identificação de estados dos objectos.

⇒ Identificação de algoritmos de implementação por

diagramas de estados e actividades

Interacções:

⇒ Especificação do comportamento de objectos representado

por troca de mensagens com um objectivo determinado.

⇒ Utilizadas para modelar o fluxo de controlo(por cada ligação

pode existir mais de uma interacção).

A mensagem especifica:

⇒ O tipo de comunicação (ex: invocar operação)

⇒ Os papeis do emissor e receptor, a acção em si e o papel da

ligação.

Representações de mensagens:
Tipo de mensagens:

⇒ Call
⇒ Return
⇒ Send
⇒ Create
⇒ Destroy

Diagramas de Interacções:

Usados para especificar a realização do “use case” ou de uma

operação que envolve mais de um objecto, por duas formas:

Diagrama de Sequencia  ênfase na ordenação temporal das

mensagens.

Diagrama de Colaboração  Ênfase na organização estrutural dos

objectos

Diagramas de Estados:

Usados para modelar o comportamento interno de um objecto ou de

um sistema (ou subsistema)

Representam:

⇒ Estados possíveis
⇒ Transacções existentes
⇒ Eventos que motivam as transacções
⇒ Operações (acções e actividades) em cada estado

“Partes” de um estado:

⇒ Nome
⇒ Acções de entrada e de saída
⇒ Transições internas
⇒ Sub-Estados
⇒ Eventos Deferidos (os que são “tratados” noutro estado)

Diagramas de Actividades:

⇒ Mostram o fluxo de controlo entre actividades do processo ou

do estado.

⇒ Focam-se na visualização das operações realizadas pelos

objectos.
 ⇒ Assemelham-se aos fluxogramas, sublinhando que actividades
são da responsabilidade de quem.

Modelação de Arquitectura:

⇒ Também chamados de implementação

⇒ Descrevem aspectos de implementação e instalação.

⇒ Podem também ser aplicados na modelação de negócios

e de organizações caso se considere que os
componentes digitais sejam procedimentos e regras de
negócios e que os componentes não digitais constituam
a infra-estrutura da organização através de recursos de
negócios.

Componentes e Nós:

componentes:

representa um conjunto de artefactos físicos em formato digital (ex:

ficheiros de código)

podem ser:

⇒ De instalação (ex: DLL’s)

⇒ De trabalho (ex: ficheiros código fonte)
⇒ De Execução (ex: processos, threads)

Nós:

Objecto físico que representa um recurso de processamento,

geralmente tendo capacidades de memoria e processamento,
podem consistir em recursos computacionais mas também em
recursos humanos.

Um nó pode conter componentes.

Semelhanças entre Componentes e Nós:

⇒ Podem participar em relações de generalização, dependência

e associação.

⇒ Podem ter instancias.

⇒ Podem participar em interacções

Diferenças entre Componentes e Nós:

Os componentes são elementos de execução de um sistema

ENQUANTO os Nós são elementos que suportam e executam
componentes.

Os componentes representam agrupamento físico de elementos

lógicos ENQUANTO os Nós representam a instalação física dos
componentes.

Diagramas de Componentes:

Usados para modelar a arquitectura de um SI na perspectiva dos

seus componentes digitais.

Ex: ficheiros de código de fonte, executáveis de configuração.

⇒ Ilustra as dependências entre vários componentes de

software.

⇒ Representa apenas tipos de componentes e nunca instancias

de componentes. Para ilustrar instancias de componentes
deve ser usado um diagrama de instalação.

Diagramas de Instalação:

Usados para modelar a arquitectura de um SI na prespectiva dos

seus componentes físicos.

Ex: computadores, equipamentos de rede

⇒ Conjunto de nós ligados por associações de comunicação

⇒ Se utilizarmos os diagramas de instalação na modelação de

processos de negócios os elementos de processamento são
unidades organizacionais e os trabalhadores enquanto que os
componentes de software são os processos e documentos
usados plas unidades organizacionais e pelos trabalhadores.