Sistemas de Informação SI: Conjunto de componentes inter-relacionados que captam, processam,

armazenam e distribuem informação para apoiar o controlo e a tomada de decisões no âmbito de uma
organização (utilização). Auxiliam gestores e funcionários a analisar problemas, visualizar soluções e também
a criar novos produtos e/ou serviços.
“Um agrupamento de pessoas, processos, dados, modelos tecnologia e linguagens parcialmente
formalizadas, formando uma estrutura coesa que serve algum propósito ou função organizacional”
Sistemas de Informação SI: 1. inclui trabalho do tipo informacional; 2. visa ajudar a atingir, no seu sentido
mais alargado, os objetivos da organização, através da recolha, armazenamento e distribuição da
informação; 3. lida com representações simbólicas, ou seja, com informação; 4. recorre às tecnologias de
informação, cada vez mais frequentemente.
Papel dos SI/TI: Reduzir erros; Reduzir custos; Adicionar valor(vantagem competitiva); Inovar.
Impacto dos SI/TI: forma como trabalho é feito; Recolha e distribuição de Informação; Estrutura
organizacional; Forma de comunicar; Tomada de decisão; Novos modelos de negócio
Alguns tipos de SI: TPS,DSS,MIS,ESS,CAI, ES,KBS,CAD,GIS,E-mail,...
Paradigmas de desenvolvimento: modelo ou padrão a ser seguido em determinada situação
Paradigmas de desenvolvimento: Processo de construção de uma solução (artefacto) para resolver um
problema; Necessidade de garantir qualidade da solução proposta; Envolvimento de diferentes especialistas
na construção da solução; Conjunto organizado de atividades bem definidas; Cada atividade tem um objetivo
específico e produz um deliverable específico; Uma comunidade aceita-o como usável para resolver
problema e propor solução com qualidade.
Engenharia de requisitos
Requisitos: Capturam um propósito de um sistema; Uma expressão das ideias a serem incorporadas no
sistema ou software em desenvolvimento; Uma afirmação sobre o sistema proposto que todos os
stakeholders concordam, para que o problema do cliente seja adequadamente resolvido.
Tipos de requisitos: Requisito Funcional eRequistio Não Funcional
Um requisito funcional (RF): está relacionado com um processo/funcionalidade que o sistema deve
executar ou com informação que o sistema deve manter. São os requisitos que, do ponto de vista do
utilizador,executam as atividades que suportam o negócio. Exemplo: O sistema deve permitir a
classificação de um veículo de acordo com a categoria a que pertencem. - Só clientes registados é que
podem fazer encomendas”. - ó aceitar encomendas desde que não ultrapasse o plafond de crédito”.
Um requisito não funcional (RNF): está relacionado com as propriedades comportamentais que o sistema
deve ter. Definem qualidades globais ou atributos do sistema;Colocam/definem restrições: no produto a
ser desenvolvido, no processo de desenvolvimento e externas que o produto deve manter. Exemplos:
integridade; segurança; usabilidade; fiabilidade. Exemplo:
- Efetuar a transação na portagem num tempo inferior a dois segundos. – Efetuar backups todos os dias,
fora da hora laboral.
Uma regra de negócio (RN): é uma premissa e/ou restrição aplicadas a uma operação por exemplo, de
forma que atenda ao negócio e funcione da forma esperada, ou seja, conforme as regras estabelecidas.
Exemplo: Só clientes registados é que podem efetuar encomendas; Só aceitar encomendas desde que não
ultrapasse o plafond de crédito do cliente
 Metodologias Ágeis
Agile: é uma metodologia de trabalho interativa e incremental onde o foco principal é a satisfação do cliente
através de entrega continua.
É um processo que ajuda as equipas a fornecer respostas rápidas e imprevisíveis ao feedback que recebem
no seu projeto. Cria oportunidades para avaliar a direção de um projeto durante o ciclo de desenvolvimento.
As equipas avaliam o projeto em reuniões regulares chamadas sprints ou iterações onde o cliente também
pode participar.
Manifesto Agile: Ao desenvolver e ao ajudar outros a desenvolver software, temos vindo a descobrir
melhores formas de o fazer. Através deste processo começámos a valorizar:
Indivíduos e interacções mais do que processos e ferramentas
Software funcional mais do que documentação abrangente
Colaboração com o cliente mais do que negociação contratual
Responder à mudança mais do que seguir um plano
Ou seja, apesar de reconhecermos valor nos itens à direita, valorizamos mais os itens à esquerda.
Processo de Desenvolvimento de Software: Waterfall (50% completo 0% usabilidade); Agile (25% completo
100% usabilidade)
Scrum
é um processo ágil que nos permite focar na entrega do que trás maior valor de negócio no menor espaço
de tempo. O Scrum permite-nos rapidamente e repetidamente (em intervalos de duas semanas a um mês)
inspecionar o “working software”. O negócio define as prioridades. As equipes auto organizam-se para
determinar a melhor forma de entregar as funcionalidades com mais alta prioridade. A cada duas semanas
a um mês, qualquer um pode ver o “working software” e decidir colocá-lo em funcionamento ou melhorá-
lo num outro sprint.
Vantagens: Grande motivação nas equipas devido ao facto de os programadores quererem cumprir o prazo
de entrega de cada sprint; O foco na qualidade é uma constante; acompanhamento do projeto por parte de
todos os membros.
Desvantagens: Falta de planeamento,a função de cada desenvolvedor não esta bem definida; é uma
abordagem iterativa, incremental e fixa no tempo. Entregar o máximo de valor possível no menor período
de tempo. Evidência problemas, Responde à mudança
Sprints: Projetos Scrum avançam em uma série de “sprints; Duração típica é de 2 a 4 semanas ou um mês
no máximo; Uma duração constante leva a um ritmo melhor; Produto é projetado, codificado e testado
durante a Sprint
Framework Scrum (estrutura do scrum): Papeis(Product owner; Scrum Master; Team) Cerimonias (Sprint
Planning; Sprint Review; Sprint Retroespective; Daily Scrum meeting) Artefactos (Poduct Backlog; Sprint
Backlog; Gráficos Burndown)
(continuaçao scrum)
Papeis
O Product Owner: Define as “features” do produto; Decide a data e o conteúdo da release; Responsável
pela rentabilidade do produto (Return On Investiment - ROI); Priorizar “features” de acordo com o seu valor
de mercado; Ajustar “features” e suas prioridades a cada iteração, se necessário; Aceitar ou rejeitar
resultados do trabalho
O Scrum Master: Representa a gestão do projeto; Responsável por propagar valores e práticas do
Scrum; “Remove” impedimentos; Garante que a equipe esteja totalmente funcional e produtiva; Permite
uma estreita cooperação entre todos os papéis e funções; Proteger a equipe de interferências externas.
Team (equipa): Tipicamente de 5 a 9 pessoas; múltiplas habilidades como programadores, testadores,
designers,...; membros devem ser alocados em full time; as equipas são auto-organizaveis; a composição da
equipa só deve ser modificada entre sprints.
Cerimonias
Sprint Planning: Equipe seleciona itens do Product Backlog com o qual se podem comprometer; Sprint
Backlog é criado; Tarefas são identificadas e estimadas (1 a 16 horas); Colaborativamente, não feito somente
pelo Scrum Master; Design de alto nível é definido.
Daily Scrum: Parâmetros (Diário, 15 minutos, Todos em pé) Não é para resolver problemas (Todos são
convidados a participar mas Somente a equipe, Scrum Master, Product Owner se podem manifestar) Ajuda
a evitar reuniões desnecessárias.
Sprint Review: A equipe apresenta o que foi concluído durante a Sprint; Geralmente na forma de uma demo
das novas funcionalidades ou arquitetura; Informal (2 horas de preparação, Sem slides); Todo a equipe
participa; Todos são convidados.
Sprint Retrospective: Periodicamente avaliar o que está e não está a funcionar Tipicamente 15 a 30
minutos; Feito após cada Sprint; Todo a equipe Scrum participa (Scrum Master, Product Owner, Equipe e
Possivelmente clientes e outros.
Artefactos
Product Backlog: os requisitos; lista com todo o trabalho desejado para o projeto; idealmente escrito de
forma a que cada item tenha valor para os utilizadores ou clientes do produto; priorizado pelo product
owner; re-priorizado ao inicio de cada sprint.
Managing Sprint Backlog: Os membros comprometem-se com trabalho escolhido por eles mesmos(trabalho
nunca é delegado por alguém); Estimativa de trabalho restante é atualizada diariamente; Qualquer membro
da equipe pode adicionar, eliminar ou modificar o Sprint Backlog; O trabalho da Sprint emerge; Se o trabalho
não está claro, definir um item no Sprint Backlog com maior tempo e decompô-lo mais tarde; Atualizar o
trabalho restante à medida que é mais conhecido. Escalabilidade: Tipicamente equipes com 7 ± 2 pessoas;
Fatores importantes no escalonamento (Tipo de aplicação Tamanho da equipe, Dispersão da equipe e
Duração do projeto)
Análise Orientada a Objetos | UML
Classe (def.) - é uma descrição de um conjunto de objetos que partilham os mesmos atributos, operações,
relações e semântica
Atributo - uma designada propriedade da classe que descreve um conjunto de valores que as instâncias da
propriedade podem assumir
Operação (ou método) - é a implementação de um serviço que pode ser requisitado por qualquer objeto
da classe para afetar o comportamento
Classes
Representam: “Coisas”, objetos, conceitos
Permitem: Modelar informação que queremos armazenar; Descrever o que é comum entre um grupo de
coisas
Podem corresponder a: Objetos físicos; Conceitos que não tenham uma existência palpável
Formadas por: Atributos; Métodos/Serviços
Atributos: descrevem o estado - Todos os elementos de uma classe são descritos por um conjunto de
propriedades (atributos) comuns a todos eles
Comportamentos: descrevem as capacidades da classe - Todos os elementos de uma classe têm
comportamentos comuns e relações comuns com elementos de outras classes.
Instâncias: Cada concretização de uma classe; Diferenciam-se pelos valores dos atributos; Partilham
atributos e métodos da sua classe.
Classes
- Todos os elementos de uma mesma classe são descritos por um conjunto de atributos comuns:
Ex.: Pessoa - nome e idade; Automóvel – matrícula, marca e modelo
- Cada instância (objeto) de uma classe distingue-se das outras instâncias por ter um conjunto de valores
diferentes para os atributos:
Pessoa: Nome: Artur Silva; Idade: 33 Nome: Pedro Costa; Idade: 18
Automóvel: Matrícula: 23-PL-45; Marca: Opel; Modelo: Corsa Matrícula: 12-PM-13; Marca: Ford; Modelo:
Fiesta
O que são métodos e mensagens?
Métodos: implementam o comportamento de um objeto (ação que o objeto pode realizar) Exemplo:
Marcar revisão; Desmarcar revisão; Criar
Mensagem: é a informação enviada a um objeto para ativar um método
O que significa UML? UML (Unified Modeling Language). Pela definição de seu nome, vemos que a UML é
uma linguagem que define uma série de artefatos que nos ajuda na tarefa de especificar, costruir,
visualizar e documentar os sistemas segundo uma perspetiva orientada a objetos.
Tipos de UML: Diagram de caso de uso, diagrama de classes,diagrama de sequancia, diagrama de objetos...
UML - Centrado- Arquitetura Três visões inter-relacionadas do sistema: funcional, estática e dinâmica
Funcional, ou externa descreve o comportamento do sistema numa perspetiva do utilizador
Estática, ou estrutural, descreve o sistema em termos de classes, atributos, métodos e relações
Dinâmica, ou comportamental, descreve o comportamento do sistema em termos de mensagens que
passam ente objetos
Qual a diferença entre classe e um objeto? Classe é um conjunto de objetos distintos, porém com as
mesmas características e comportamentos. A classe é uma abstração de entidades existentes no mundo
real (ex.: pessoa, animal, publicação,...). Objeto é uma instância ou modelo derivado de uma classe.
Portanto objeto é a representação de qualquer coisa, real ou abstrata, do mundo real que irá ser
manipulado ou armazenado pelo sistema. O objeto sempre será uma instância ou um elemento da uma
classe (ex.: pessoa-> joao; pessoa->jose | animal->Bilú | publicação->Livro; publicação-> revista)
Qual o objetivo principal dos diagramas de estrutura? Os diagramas de estrutura são utilizados para fazer
a modelagem de colaborações. Uma colaboração descreve uma visão de um conjunto de instâncias que
cooperam entre si para executar uma tarefa específica. Da mesma forma, apresenta as ligações entre as
instâncias e os papéis que as mesmas representam para a respectiva tarefa.
O que significa, para o DSOO, incremental e iterativo? Um processo iterativo é aquele que faz progresso
através de tentativas sucessivas de refinamento. Por exemplo, uma equipe de desenvolvimento faz sua
primeira tentativa para construção de um software, porém, existem pontos de informação falhos ou
incompletos em algumas (talvez muitas) partes. A equipe de forma iterativa refina essas partes até que o
produto atinja o ônus de satisfatório. Com cada iteração, o software é melhorado através da adição de
mais e mais detalhes. Um processo incremental é aquele em que o software/produto é construído e
entregue por pedaços. Cada pedaço ou incremento representa um subconjunto de funcionalidades
completas. O incremento pode ser pequeno ou grande, por exemplo, ele pode variar apenas de uma tela
de relatórios simples, para um conjunto altamente flexível de telas de gerenciamento de dados. Cada
incremento é totalmente codificado e testado, e a expectativa geral é que o trabalho tenha a conclusão
mais completa possível.
Métodos ágeis são tanto iterativos, quanto incrementais. São iterativos por que o trabalho realizado é
sempre melhorado em ciclos subsequentes. São também incrementais, por que o trabalho planejado é
entregue em partes que são adicionadas ao todo do projeto.
Compare as fases do Unified Modelling Process com as do Waterfall model.
 Diagramas de caso de Uso
Diagrama usado para representar requisitos funcionais do sistema em desenvolvimento; Elaborado sob a
perspetiva dos utilizadores do sistema; Elaborado nos passos iniciais do processo de desenvolvimento;
Diagrama usado para comunicar o comportamento do sistema segundo a perspetiva do utilizador
(comportamento visível); Diagrama simples e não mostra detalhes dos casos de uso; Não mostra a ordem
para atingir os objetivos de cada caso de
uso; Serve a fase de implementação e permite gerar testes
Captura os requisitos do sistema e ilustra a interação entre o sistema e o ambiente;Modelo de caso de uso
é composto por um ou mais diagramas de casos de uso; Modelo de caso de uso deve ser elaborado sob a
perspetiva dos stakeholders do sistema e não sob a perspetiva do “construtor”
Actor: “quem” interage com o sistema Pode ser uma pessoa, um grupo de pessoas (papel), outro sistema,
máquinas ou um dispositivo. Caso Uso: qualquer uso que os atores realizam no sistema de forma a
satisfazer o objetivo do utilizador (ator). Ligação: a associação entre atores e casos de uso. Fronteira do
sistema: delimita o sistema que foi definido na identificação de requisitos
Objetos de modelação utilizado
Ator: O nome deve refletir o papel que o utilizador tem no sistema ou o nome do sistema ou equipamento
Ex: Vendedor, Sistema de contabilidade, Máquina ATM
Caso de uso: O nome atribuído deve ser um verbo e um nome que deve ter origem nos requisitos e deve
ser conhecido do ator que usa o caso de uso
Ex: Procurar artigo, Comprar casa, Validar utilizador
Uses ou Include: Significa que um determinado caso de uso utiliza a funcionalidade dispensada num outro
caso de uso. A chama sempre B A--------->B
Extend: Ocorre quando existe um comportamento opcional que deve ser incluído num caso de uso. Este
comportamento é incluído num segundo caso de uso e invocado pelo caso de uso base. A chama as vezes
B. A<---------B
 Descrição de Caso de Uso
Descrevem de uma forma mais detalhada os diferentes aspetos de cada Caso de Uso.
Contém a informação necessária para documentar o que o utilizador pode fazer para interatuar com o
sistema (cenários).
Construídos com base nos requisitos do sistema.
Descrição da relação do ator com o Caso de Uso :
- Generalizada (independente da forma como vai ser implementado)
- Detalhada (como a utilização vai ser implementada)

NOME: Verbo e nome (o indicado no diagrama de caso de uso)

ATOR: Quem ativa (despoleta) o caso de uso (o indicado no diagrama de caso de uso)
BREVE DESCRIÇÃO: Texto o curto que explica objetivo do caso de uso
PRÉ-CONDIÇÃO: Condição que tem de se verificar para o caso de uso poder ocorrer
SEQUÊNCIA NORMAL DE FLUXOS - Descrição: Diferentes passos necessários para caso de uso ocorrer
dentro da normalidade esperada Cada passo deve ser descrito sempre que possível mostrando: sujeito –
verbo (ação) – objeto mostrar quem inicia a ação:
- cada passo é descrito com o mesmo nível abstração
- cada passo representa o mesmo nível de importância para completar o caso de uso
FLUXOS EXCECIONAIS/ ALTERNATIVOS: Fluxos que podem acontecer mas não são normais
PÓS-CONDIÇÃO: Estado final do sistema após a realização do caso de uso
Emprestar livro
Autor Funcionário
Breve descrição O caso de usa regista um empréstimo de livro de um aluno
Pré-condição O funcionário é um utilizador válido no sistema
1. O caso de uso inicia quando o funcionário seleciona a opção Emprestar
Livro
2. O sistema pede a identificação do livro
3. O funcionário insere a identificação do livro
Descrição
4. O sistema lê e mostra a disponibilidade do livro
(sequência normal de
5. O sistema pede a identificação do aluno
fluxos)
6. O funcionário insere a identificação do aluno
7. O sistema regista o empréstimo do aluno
8. O sistema imprime o recibo do empréstimo

A qualquer momento o funcionário pode cancelar o empréstimo.

Cenário alternativo Livro indisponível
1. Apresentar aviso ao aluno
Pós-condição O livro fica indisponível