Software

14-03-2012

1

Bases de Dados

Paulo Azevedo

Objectivos

• Aquisição de um processo simplificado de

desenvolvimento de soluções de software,

baseada na utilização da notação UML e

técnicas associadas.

Paulo Azevedo - Fev/2012 2

14-03-2012

2

Produção de software

• A produção de software é frequentemente

uma actividade não estruturada, sem

orientações de natureza estratégica e sem

planos de gestão e controlo;

• Os problemas associados ao desenvolvimento

de software são tão complexos que é

necessário a utilização de princípios, regras e

estratégias que conduzam a melhorias.



• Definir o tipo de intervenção e conjugar

correctamente as interacções entre as

pessoas, o processo aplicado, as

características do produto e o projecto que

orienta as actividades a desenvolver.

• Regra dos quatro “P’s”.


14-03-2012

3


Regra dos quatro “P’s”:

– Pessoas – Só com Motivação e compromisso é que

se consegue garantir o sucesso;

– Processo – Com técnicas e regras bem definidas;

– Produto – Compreendendo as necessidades reais

dos utilizadores obtemos um resultado com

qualidade;

– Projecto – Deve ser credível e controlado para

cumprir prazos e custos propostos



Um projecto de sistemas de informação deveresponder – W5H2 (Barry Boehm 1996):

– Porque é que vai ser desenvolvido WHY;

– O que vai ser feito/deve ser feito WHAT;

– Quando é que vai ser feito WHEN;

– Quem é o responsável WHO;

– Onde estão as responsabilidades WHERE;

– Como é que vai ser feito HOW;

– Quanto vai custar HOW MUCH.


14-03-2012

4


Processo de desenvolvimento de sw é uma

sequência de actividades, agrupadas em fases,

executadas de forma sistemática e

uniformizada, realizadas por intervenientes

com responsabilidades definidas em que a

partir de um conjunto de entradas se

produzem um conjunto de saídas. Tem quatro

objectivos fundamentais.



Objectivos do Processo de desenvolvimentode sw:

1. Providenciar orientação sobre a sequência derealização das actividades;

2. Especificar modelos descritivos do sistemaque devem ser desenvolvidos;

3. Dirigir tarefas dos participantes e da equipa;

4. Providenciar critérios para monitorização eavaliação dos modelos.


14-03-2012

5


Metodologias de desenvolvimento de sw

sequência de etapas e procedimentos

recomendados para serem aplicados durante

o processo de desenvolvimento de SI.

Acrescenta a utilização de um conjunto de

ferramentas, técnicas e notações.

Inclui referências a princípios e regras para

concretizar na prática regras teóricas



Princípios Metodologias de desenvolvimento sw:

• Elaborar estimativas (custos/prazos);

• Técnicas para efectuar medições;

• Procedimentos para garantir qualidade;

• Programas de formação;

• Modelos de documentação a produzir;

• Modelos práticos;

• Técnicas para configuração de metodologia.


14-03-2012

6


Um modelo consiste na interpretação de um

dado domínio do problema, segundo uma

determinada estrutura de conceitos.

Um esquema é a especificação de um modelo

usando uma determinada linguagem, formal

ou informal. A representação gráfica de um

esquema é um diagrama.



A modelação é a arte e a ciência de criar

modelos de uma determinada realidade.

Técnica aceite pela generalidade das

disciplinas conhecidas. Permite a partilha de

conhecimento entre grupos intervenientes.


14-03-2012

7


Benefícios da modelação:

• Modelos ajudam a visualizar um esquema;

• Permitem especificar a estrutura ou

comportamento de um sistema;

• Controlar e guiar o processo de construção do

sistema;

• Documentam decisões tomadas.



A Evolução das técnicas e metodologias de

modelação divide-se em duas fases (Rumbaugh,

1996):

1. Aproximação estruturada ou funcional;

2. Aproximação baseada no paradigma dos

objectos.


14-03-2012

8


Aproximação estruturada ou funcional:

• Diversidade de autores propõem abordagens

especificas e nomenclaturas distintas para a

modelação de sistemas de informação;

• Grande diversidade de propostas tornava

difícil a comunicação e reduzia a utilidade

prática desta área de conhecimento;



Aproximação estruturada ou funcional (cont.):

• Diferenças nos modelos semânticos, notação

sintáctica e diagramas originaram uma

proposta unificadora;

• SSADM, Yourdon.


14-03-2012

9


SSADM:

• Metodologia de referência e ensinada emdiversos cursos universitários;

• Diagramas de Fluxos de Dados;

• Diagramas Entidade Relação;

• Diagramas de Ciclo da Vida das Entidades;

• Focada na análise e desenho do sistema, nãocontempla tarefas relacionadas com aimplementação.



Yourdon:

• Baseada da filosofia da decomposição

funcional (top down);

• Suportada na utilização de DFD;

• Recorre muito à decomposição funcional;

• Atribui importância significativa à estrutura de

dados.


14-03-2012

10


Aproximação baseada no paradigma dos

objectos:

• Notação padronizada, constituída por um

conjunto limitado de elementos que podem

ser tipificados em diagramas, abstracções e

relacionamentos.



Booch, Jacobson e Rumbaugh iniciaram umtrabalho para apresentar uma propostaunificadora dos seus trabalhos individuais.

Este trabalho deu origem ao UML (UnifiedModelling Language), apresentadopublicamente em Outubro de 1995.

Em Novembro de 1997 a UML foi adoptadapela OMG como linguagem de modelaçãopadronizada.


14-03-2012

11


Contribuições para o UML:


UML

Wirfs-Brock

1990

Coad-Yourdon

1991

Gamma et al.

1995

Wirfs-Brock

1997

Shlaer-Mellor

1989

Rumbaugh

1991

Booch

1994

Jacobson

1995

V 1.3

1999

V 1.5

2003

V 1.0

1997

V 1.4

2001

V 2.0

2004


Actualmente na versão 2.0.

Esta versão demonstra um grau de

maturidade da linguagem, utilizando

princípios da meta-modelação para definir os

conceitos do UML através da própria

linguagem.


14-03-2012

12

UML


UML

• Resultado de um longo processo de maturação

no domínio da modelação.

• Fornece uma linguagem universal para

especificação de software.

• A utilização da notação UML deve ser

enquadrada pela adopção de um processo que

estruture o trabalho de desenvolvimento:

– O que deve ser feito;

– Como deve ser feito, como fazer (técnicas a utilizar).


14-03-2012

13

UML

• Um modelo UML é constituído por um conjuntode diagramas que representam aspectoscomplementares de um SI.

• Em cada um destes diagramas são utilizadossímbolos que representam os elementos queestão a ser modelados (abstracções) e linhas querelacionam esses elementos.

• Os símbolos e as linhas têm significado especificoe possuem formas distintas, constituindo ummodo de notação.


UML - Diagramas

O UML disponibiliza o seguinte conjunto de diagramas:

1. Diagrama de Use Cases;

2. Diagrama de Classes;

3. Diagrama de Objectos;

4. Diagrama de Sequência e Diagrama de Colaboração;

5. Diagrama de Actividade;

6. Diagrama de Estados;

7. Diagrama de Componentes;

8. Diagrama de Instalação


14-03-2012

14

UML – Diagrama de Use Cases

Serve para identificar as fronteiras do sistema

e descrever os serviços (use cases) que devem

ser disponibilizados a cada um dos diversos

utilizadores (actores).


UML – Diagrama de Classes

Através do qual descrevemos a estrutura da

informação (classes e suas relações) que é

utilizada no sistema.


14-03-2012

15

UML – Diagrama de Objectos

Utilizado para ilustrar um diagrama de classes

com um exemplo concreto.


UML – Diagrama de sequência e

colaboração

Ilustram como os objectos do sistema

interagem para fornecer a funcionalidade do

use case. Estes diagramas designam-se

genericamente por diagramas de interacção.


14-03-2012

16

UML – Diagrama de Actividade

Pode ser utilizado para descrever cada um dos

use cases, realçando o encadeamento de

actividades realizadas por cada um dos

objectos do sistema, numa óptica de fluxo de

trabalho.


UML – Diagrama de Estados

Utilizado para modelar o comportamento dos

objectos, isto é, descrever as alterações nos

valores de atributos dos objectos em

resultado da ocorrência de certos eventos .


14-03-2012

17

UML – Diagrama de Componentes

Utilizado para descrever a arquitectura da

aplicação informática em termos de

componentes de software


UML – Diagrama de Instalação

Permite descrever a arquitectura de

equipamento informático utilizado e

atribuição dos componentes da aplicação aos

diversos equipamentos.


14-03-2012

18

• Métodos que se baseiam na utilização da

notação UML:

– Rational Unified Process2 (RUP), da Rational

Software, por Philippe Kruchten, Ivar Jacobson e

outros;

– Extreme Programming3 (XP), por Kent Beck e

outros;

– Feature Dreaven Development4 (FDD), por Peter

Coad;

UML


UML

• No projecto de desenvolvimento que aqui

exploramos, vamos utilizar um Processo

Simplificado. O objectivo não é discutir um

Processo completo e com alguma

complexidade, mas mostrar a aplicação da

UML de uma forma ágil e consequente.


14-03-2012

19

Modelação de software

• Um projecto de desenvolvimento engloba trêsgrandes etapas (ver figura):– Análise da Organização (análise estratégica,

levantamento de requisitos, etc.);

– Especificação do sistema de software que responda às necessidades identificadas;

– Implementação e instalação da solução


Processo de desenvolvimento

Especificação do

sistema de SW

Análise do

negócioImplementação

Técnicas;

Instrumentos;

Ferramentas.

Técnicas;

Instrumentos;

Ferramentas.

Técnicas;

Instrumentos;

Ferramentas.

Implementar um mini-projecto para a gestãode um ponto de venda de uma loja. Oproblema pode ser formulado nestes termos:

“A empresa ABC necessita de um sistema

informático para registar as vendas, que têm

lugar na loja, ao consumidor final, assim como

os respectivos pagamentos.”

Sabemos o que queremos fazer! Mas, poronde começar?

Exemplo


14-03-2012

20

• Preparar - investigar a área do problema e fixar

os requisitos e âmbito da solução;

• Construir - analisar o problema, e construir

modelos abstractos de resolução. Destes

modelos, evoluir para especificações lógicas da

solução pretendida e, finalmente, implementar

numa linguagem de programação.;

• Instalar - transferir a solução para os ambientes

reais de produção.

Ciclo de vida


Ciclo de vida


Preparar Construir Instalar

Compreensão do problema;

Requisitos e âmbito do

sistema;

Plano de projecto.

Modelos de Análise e

Desenho;

Protótipo operacional.

Transferência para

ambiente de produção

14-03-2012

21

A fase Preparar envolve actividades para as

quais não é particularmente importante ser

versado em competências "Orientadas ao

Objecto". O principal objectivo é identificar

claramente quais são os requisitos do sistema

a desenvolver de modo a suportar o

planeamento, avaliação do risco e benefícios,

bem como colher o compromisso de avançar

junto do “cliente”.

Fase 1 - Panorâmica


A análise de requisitos é uma disciplina só por

si, para além do âmbito deste texto. A bem da

simplicidade, vamos abreviar e avançar uma

listagem informal de requisitos. No nosso caso

de estudo, vamos limitar-nos ao processador

de texto Microsoft Word. Verdadeiramente

importante é que neste processo não sejam

omitidos requisitos!

Fase 1 – Definir requisitos


14-03-2012

22

Fase 1 – Definir requisitos


Empresa ABC

1 – Propósito

-…

-…

2 – Objectivos

-…

-…

3 – Cliente

-…

4 – Requisitos funcionais

-RF1

-RF2

5 – Atributos do sistema

Performance; Interfaces

• Os requisitos devem ser numerados de forma

a poderem ser rastreados nas fases

subsequentes do desenvolvimento.

Regra prática


14-03-2012

23

Quais os requisitos essenciais para uma solução

de posto de venda para a empresa ABC?


Problema:





Exemplo


14-03-2012

24

Diagramas CU

• Representa uma acção entre um utilizador

(humano ou máquina) e um sistema;

• Descrevem a funcionalidade que um actor

necessita de executar para obter um

determinado resultado, um objectivo;

• Diagramas de alto nível, pouco detalhados;

• Sequência de acções que um ou mais actores

realizam num sistema [OMG99].


Diagramas CU

• O Diagrama de CU funciona frequentemente

como instrumento de comunicação com os

utilizadores.

Actores

Casos de Utilização

ACTOR

Caso de Utilização


14-03-2012

25

Diagramas UC

• Actor – Papel que um utilizador desempenha

relativamente ao sistema em análise. Também

pode corresponder a um SI ou hardware.

• Caso de Utilização – Especificação de uma

sequência de acções que um sistema pode

realizar interagindo com actores do sistema.


• Os UC são modelados como elipses;

• Os UC devem começar com um verbo no

infinitivo. Esta técnica dá enfoque à natureza

funcional dos UC. Por exemplo:

– “Levantar dinheiro”;

– “Agendar consulta”;

– “Efectuar inscrição”.

• Actores, figuras estilizadas de pessoas.

Regras Práticas


14-03-2012

26

Exemplo

Aluno

Efectuar Inscrição

Aplicação GesEscola


Cenário Principal e Secundário

A descrição do cenário pode assumir a forma

de texto livre ou estruturada, segundo um

conjunto de passos numerados.

As especificações do cenários devem incluir:

– Pressupostos;

– Pré-condições;

– Inicialização;

– (…).


14-03-2012

27

Cenário

Forma livre

Caso de utilização inicia-se quando o aluno

acede ao sistema GesEscola, selecciona uma

escola, verifica os cursos existentes e efectua a

sua inscrição no curso. Termina após inscrição.


Cenário

Forma estruturada


Efectuar Inscrição

Pré condição Aluno é utilizador válido.

1 – UC começa quando aluno selecciona a opção efectuar

inscrição;

2 – Sistema mostra lista de escolas;

3 – Aluno selecciona escola;

4 – Sistema mostra lista de cursos;

5 – Aluno selecciona curso;

6 – Aluno efectua inscrição.

Pós condição Aluno recebe comprovativo da inscrição.

14-03-2012

28

Proposta

Com base nos requisitos identificados naempresa ABC vamos construir um modelo decasos de utilização de alto nível.

1. Enumerar os actores que interagem com osistema;

2. Levantar casos de utilização (UC) do sistema.






Proposta


14-03-2012

29

Regras Práticas

Duas técnicas para levantamento de UCs

• Baseadas no actores:

– Identificar os actores relevantes relacionados com osistema ou organização;

– Para cada actor, identificar os processos que ele iniciaou participa.

• Baseada em eventos:

– Identificar eventos do exterior que a empresa tem deresponder;

– Relacionar os eventos com actores e UCs.


Regras Práticas

• Depois de identificados, os UC são especificadosatravés de descrições textuais estruturadas. O nível dedetalhe é variável, podendo a descrição centrar-se naintenção do UC (chamado de essencial – foco naessência do processo) ou detalhar a suaimplementação concreta (chamado de real).

• Um UC essencial não está dependente de tecnologiade implementação enquanto que um UC real refere asopções concretas da sua realização ("Introduzir códigodo produto" vs. "Ler código através de um leitor ópticode códigos de barras").


14-03-2012

30

Regras Práticas

No processador de texto, escrever cada UC no

modo essencial.


Regras Práticas

De forma a evidenciar o actor, a descrição

geral do UC pode iniciar-se com uma estrutura

padrão do tipo:

• <Actor>;

• <Verbo>;

• <Acção>.


14-03-2012

31

Regras Práticas


Descrição detalhada do UC


14-03-2012

32

Descrição detalhada do UC


Proposta

Durante o semestre o Prof. Faísca foi enviando

os sumários com breves resumos da matéria

leccionada, via e-mail, para o sistema Fly2.

Após o fim das aulas, o Prof. Faísca utilizou a

interface web do sistema para actualizar cada

um dos sumários com descrições mais

completas das matérias leccionadas. Finda

essa actualização imprimiu os sumários e

enviou-os à Secretaria.


14-03-2012

33

Proposta

Neste caso identificamos os seguintes UCs:

1. Enviar sumários via e-mail;

2. Actualizar sumários via web;

3. Imprimir sumários (via web?/via e-mail?);

4. Enviar sumários à secretaria — deverá este use case serconsiderado?

No cenário descrito o envio é feito em papel. Não se trata,portanto, de um serviço fornecido pelo sistema. No entanto,podemos discutir a possibilidade de o envio passar a ser feitoelectronicamente.

Durante o semestre o Prof. Faísca (1.) foi enviando os sumários combreves resumos da matéria leccionada, via e-mail, para o sistemaFly2. Após o fim das aulas, o Prof. Faísca (2.) utilizou a interface webdo sistema para actualizar cada um dos sumários com descriçõesmais completas das matérias leccionadas. Finda essa actualização(3.) imprimiu os sumários e (4.) enviou-os à Secretaria.


Proposta

Neste caso identificamos os seguintes Actores:

1. Docente;

2. Aluno;

3. Secretaria.

“Quem vai usar o sistema”


14-03-2012

34

Proposta


Diagrama de UC

Relações entre UC

As relações mais frequentes entre UC são<<include>> e <<extend>> e generalização.

<<Include>> ou <<uses>> - Significa que umdeterminado UC utiliza ou inclui a afuncionalidade disponibilizada noutro UC;

<<extend>> - Ocorre quando existe umcomportamento opcional que deve ser incluídonum UC;

Generalização – Quando existe um caso particularde outro UC.


14-03-2012

35

Include

Neste diagrama utiliza-se a relação <<include>>para demonstrar que a funcionalidade “controlode acesso” é utilizada quando a encomenda éfeita pela internet. Alguns autores utilizam<<uses>> em vez de <<include>>. Esta relação éútil para evitar a duplicação de UC.


Extend

O mecanismo de pontos de extensão permite definirno UC base onde o comportamento será incorporado,sem alterar a sua descrição. Também garante que ocomportamento não se altera se ele deixe de existirNeste diagrama utiliza-se a relação <<extend>> parademonstrar que a funcionalidade “Desconto internet”pode ser aplicada.


14-03-2012

36

Generalização

O comportamento do UC “efectuarencomenda internet” é semelhante ao UC“efectuar encomenda”, existindo apenasvariações especificas do meio onde éefectuada a encomenda.


Generalização

A generalização possui as mesmas propriedadesque uma relação “pai/filho”, onde o UC filhoherda ou substitui por completo ocomportamento do UC pai, por exemplo o UC“controlo de acesso” pode ser realizado de duasformas diferentes, consoante seja efectuado naloja ou na internet.


14-03-2012

37

Generalização

A relação também pode ser efectuada entre doisactores. No exemplo é estabelecido uma relaçãode generalização entre o actor “funcionário” e oactor “empregado de balcão” (caso geral -> casoespecífico). Esta relação evita a duplicação derelações.


Generalização

O que significa esta generalização?.


14-03-2012

38

Generalização

Ilustre a seguinte generalização entre osactores: Patrão e Empregado. Ambos sãorecursos humanos de uma organização:

“Todas as manhãs os recursos da organização

registam a hora de entrada no relógio de

ponto da empresa ABC. Semanalmente, o

patrão extrai o registo de horas do relógio e

envia a listagem para o departamento de

recursos humanos.”


Revisão

Perguntas de revisão:

1. O que significa Use Case?

2. Qual a notação para Use Case?

3. O que significa Actor?

4. Qual a notação para Actor?

5. Para que servem os diagramas de UC?

6. Defina conceito de requisito.

7. Que tipos de requisitos existem?

8. Que tipos de relação podem ser efectuadas entre UC?

9. Qual a diferença entre <<extend>> e <<include>>?


14-03-2012

39

Revisão

1. O que significa Use Case?

Constituem a técnica UML para representar olevantamento de requisitos de um sistema.Desde sempre que o correcto levantamento derequisitos no desenvolvimento de sistemas deinformação tenta garantir que o sistema seja útilpara o utilizador final, estando de acordo com asnecessidades


Elipse


Revisão


3. O que significa Actor?

Um actor representa uma entidade externa queinterage com o sistema.

Devem ser caracterizados através de umpequena descrição, de forma a assegurar umacorrecta compreensão do significado do actorpor todos os elementos da equipa envolvida daanálise.


Figuras estilizadas de pessoas

14-03-2012

40

Revisão

5. Para que servem os diagramas de UC?

Para apresentação de requisitos e para

assegurar que tanto o utilizador final como o

perito numa determinada área, ou o

especialista informático possuem um

entendimento comum dos requisitos. O

objectivo é mostrar o que um sistema deve

efectuar e não como o vai fazer.


Revisão

6. Defina conceito de requisito

Funcionalidade ou característica considerada

relevante na óptica do utilizador.

Normalmente, representa um

comportamento esperado do sistema, que na

prática consiste num serviço que deve ser

disponibilizado a um utilizador.


14-03-2012

41

Revisão

7. Que tipos de requisitos existem?

Funcionais – Descrevem o que o sistema faz, ou sepretende que faça. Requisitos levantados inicialmente.Descrição de processamentos a efectuar pelo sistema,inputs e outputs;

Não funcionais – Relacionados com as característicasqualitativas do sistema, descrevendo a qualidade com queo sistema deverá fornecer requisitos funcionais (temposde resposta);

Usabilidade – Garantem uma boa relação entre o sistemadesenvolvido, utilizadores do sistema e também as tarefasque desempenham apoiados pelo sistema.


Revisão

8. Que tipos de relação podem ser efectuadas entre UC?

<<extend>>; <<include>> e generalização

9. Qual a diferença entre <<extend>> e <<include>>?

<<include>> - Significa que um determinado UC utilizaou inclui a a funcionalidade disponibilizada noutro UC;

<<extend>> - Ocorre quando existe umcomportamento opcional que deve ser incluído numUC;


14-03-2012

42

Exercícios

De uma entrevista com o responsável de biblioteca deuma universidade resultou a seguinte descrição para umnovo SI:

“Uma das actividades principais da biblioteca é efectuar oempréstimo de publicações aos alunos da universidade. Oempréstimo é registado pelos funcionários da biblioteca,que também consultam diariamente os empréstimoscujos prazos foram ultrapassados. Todo este processo érealizado manualmente, sendo muito ineficiente. Espera-se que o novo sistema resolva esta situação. Os alunosnecessitam de pesquisar livros existentes na biblioteca.Caso um livro esteja requisitado, é mostrada a dataesperada de entrega.”


Exercícios

Considere os seguintes requisitos de um SI para gestão de umparque de estacionamento.

a) O controlo é efectuado com base na matrícula do veículo;

b) Na entrada do parque existirá um funcionário que introduz asmatrículas do sistema, ficando de imediato registado a data e horade início de estacionamento. O sistema tem de verificar as amatrícula existe;

c) Se a matrícula não for reconhecida pelo sistema, então ofuncionário registará um novo veículo no sistema;

d) Na saída, um funcionário introduz novamente a matrícula,calculando o sistema o custo do estacionamento;

e) O gestor do parque de estacionamento precisa de consultardiariamente uma listagem dos estacionamentos. Em algumassituações, o gestor poderá desempenhar as funções deatendimento, no entanto, apenas o gestor poderá obter listagens.


Education

Software