ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS

--------------------------------------------MÓDULO 1---------------------------------------------

LEI DE MOORE-

Aumento da capacidade de processamento; Diminuição do custo de produção; Computadores menores – com

componentes internos que também reduziram; Computadores mais confiáveis com maior número de transitores em
uma pastilha; Diminuição do consumo de energia.

Sistema de informação X Software –

Com os problemas do software surgiu o sistema de informação, que possui informações(dados), pessoas, processos,
tecnologias (infraestrutura de hardware, telecomunicação e sistemas de software), com objetivo de melhorar os
negócios de uma corporação.
Deve-se entender primeiro é entende o processo de negócio do cliente, ou seja qual objetivo do projeto, pensar na
plataforma tecnológica, automatizar um processo e criar um problema automatizado e modelar um sistema de
informação, é nesse caso é válido pensar qual parte do processo seria automatizada por um sistema de SOFTWARE.

PROCESSO DE DESENVOLVIMENTO
Para desenvolver um software, isso vai além de uma digitação de linhas de código, tem de entender as necessidades
do negócio e a cultura do cliente, entender até onde vai o sistema de informação e tentar alcançar a qualidade no
projeto.
PILARES DO DESENVOLVIMENTO:
Métodos: conj de atividades de como fazer para desenvolver um sist de software.
Ferramentas: mecanismos que dão suporte à execução das atividades descritas no método.
Processos: juntas os métodos e ferramentas, definindo quando e onde fazer, indicando a sequencia de execução das
atividades, quais ferramentas utilizar e quem dever ser o responsável pela atividade.

Processo: conjunt de atividades executadas em uma determinada sequência e quais atividade serão executadas em
sequência; atividades devem ser executadas por pessoas q podem ser chamadas de papéis e devem produzir
resultado(artefatos); Papéis são responsáveis pelas atividades: analistas, projetistas, arquitetos de software;
desenvolvedores, clientes, avaliadores de qualidade.
Atividades fundamentais p engenharia de software: especificação de software; projeto e implementação de software;
validação de software e evolução ou implantação de software.
MODELOS DE ENG DE SOFTWARE:
Cascata; incremental; prototipagem; espiral e unificado;

PARADIGMA: conj de regras que estabelecem fronteiras entre o que é certo e errado, e entre o verdadeiro e o falso;
é uma forma de pensar e fazer o desenvolvimento de software; Ou seja é um método que caminha junto com o
desenvolvimento de software.
A orientação a objetos se dá pela tentativa de aproximar o desenvolvimento de software daquilo que acontece no
mundo real, sendo apoiado nos pilares: classe e objeto; abstração; encapsulamento; herança; poliformismo e ligação
e mensagem. Ela não é uma linguagem de promgração, não é uma plataforma de desenvolvimento; não é um
processo de desenvolvimento e não é uma ferramenta; Ela é confundida com UML, o que é errado.
UML: ferramenta de apoio, é uma linguagem de modelagem visual de sistemas orientada a objetos, possuindo
elementos gráficos de modelagem que representam visões de ums sitema de software que possui regras de sintaxe
e semântica;
---------------------------------------MÓDULO 2--------------------------------------------------

ENGENHARIA DE REQUISITOS:
Tem os fatores de insucesso e sucesso.
Fases “clássicas” de um projeto de software: análise de requisitos; projeto; implementação; testes e implantação.
Requisitos: são serviços que um sistema deve prestar e as suas restrições, sendo um conj de métodos,
procedimentos e ferramentas de funcionamento que vai refletir nas necessidades dos clientes, com intuito de
analisar, documentar, verificar e validar esses requisitos, ou seja, essa parte vai envolver as atividades relacionadas
aos ciclos.
Desafios: definição de requisitos inconscientes que leva a problemas que se estende por todo o ciclo de vida do
software, e requisitos mal definidos gera maior custa e maior tempo p desenvolver, e falhas geram u sistema com alto
custo de manutenção.
OBJETIVO: mapear as necessidades do negócio, montar um modelo que represente esses requisitos e que possa
servir como guia de comunicação para todos os interessados.
-Stakeholder: nome dado para os diversos interessados ou envolvidos no projeto, ou seja, cada steak tem uma
determinada necessidade para um determinado ponto de vista. Ex: cliente x desenvolvedor. Por isso
SOMMERVILLE(2010) sugere a separação dos requisitos a partir do seu nível de descrição: requisitos de usuário e
requisitos de sistema.
-Requisitos de usuário: declarações em linguagem natural, com diagramas de quais serviços o sistema deverá
fornecer a seus usuários e as restrições com as quais que ele deve operar (direcionados aos clientes, usuários,
gerentes de projeto e arquitetos de sistemas).
-Requisitos de sistema: descrições mais detalhadas das funções, serviços e restrições operacionais do sistema de
software(direcionados a usuários, arquitetos de sistema e desenvolvedores, pois podem definir uma sequencia de
implementação, o que influencia diretamente a solução dada

-Requisitos funcionais: descrevem o comportamento esperado de um sistema de software, explicitam o que o sistema
deve fazer, e o que o sistema deve não fazer.
-Requisitos não funcionais: descrevem restrições sobre os serviços oferecidos pelo sistema de software e chamados
tbm de atributos de qualidade.

PROCESSOS DE ENGENHARIA DE REQUISITOS

Elicitação é a descoberta dos requisitos a partir das fontes de requisitos, utilizando técnicas de elicitação: entrevistas;
cenários, protótipos, reuniões facilitadas, observação e análise de documentos.
Análise e negociação: os requisitos são analisados e os conflitos resovidos, sendo produzido um modelo de sistema
com os requisitos do usuário.
Documentação: os requisitos são detalhadas de tal modo que permitam a realização das próximas atividades do
desenvolvimento, é produzida a especificação dos requisitos contendo os requisitos de usuário e de sistema;
documento de definição de sistema; especificação de requisitos de sistema e especificação de requisitos de software.
Validação: os requisitos são validados de acordo com os critérios definidos na documentação dos requisitos.

GERENCIAMENTO DE REQUISITOS: requisitos sempre mudam, eles podem ser completos, inconsistentes e pode
também surgir novos. Gerenciar o relacionamento entre requisitos e gerenciar o relacionamento entre requisitos e os
documentos produzidos durante todo o projeto. Controle de versão e rastreabilidade.

MODELAGEM DE CASOS DE USO

Esse modelo ira abordar a combinação de método e ferramenta e cumpre os objetivos a serem atingidos na fase de
análise de requisitos, ela é uma representação das funcionalidades externamente observáveis do sistema e dos
elementos externos ao sistema que interagem com ele. Um caso de uso é a descrição de uma determinada ação ou
comportamento de um sistema, que produz um resultado para um determinado agente externo a esse sistema,
denominado ator. Se eles são bem descritos e definidos, casos e uso definem um denominador comum, de
conhecimento do domínio do problema e das funcionalidades do sistema que podem ser interpretados facilmente por
usuários analistas e desenvolvedores.
Principais elementos de um modelo de caso de uso: caso de uso, ator.
-Ator: são os agentes externos ao sistema, que executam uma determinada ação e que esperam algum resultado, ou
seja, interagem diretamente com o sistema a partir dos casos de uso(entidade externa que interage com o sistema:
usuários, outros sistemas de soft ou dispositivos de hardware)
Casos de uso é a descrição de uma sequencia de atividades executadas por um agente externo ao sistema sem que
sejam revelados detalhes do funcionamento interno ao sistema, por isso dizemos que o caso de uso mostra a visão
comportamental externa ao sistema.
IMPORTANTE: descrição de caso de uso = um requisito deve ser completo.
LINGUAGEM NATURAL, mas como elementos fundamentais: identificação do caso de uso; escopo, descrição do
proposto, ator primário, pré-condições e pós-condições, fluxo normal e fluxo alternativo e requisitos relacionados.

DIAGRAMA DE CASOS DE USO: diagrama de caso de uso e um diagrama UML, q tem por objetivo mostrar, a partir
de um ponto de vista estático, o conjunt de casos de uso, atores e seus relacionamentos. DIAGRAMA NO SLIDE.

-----------------------------------------MÓDULO 3------------------------------------------------

MODELAGEM DE PROCESSO DE NEGÓCIO

Executadas por agentes, de uma determinada forma, de um determinado espaço de tempo, em determinada
condição de ambiente e com um finalidade, se chama dos 5W1H(what, who, When, Where e why e----- how).
Modelo clássico de processo de negócio é o fluxograma, q representa a sequencia em que as atividades são
executadas, representando os principais elementos do processo de negócio, seus significados e inter-relações, e no
caso essa modelagem completa a modelagem dos casos de uso.
Esse modelo terá o ponto de vista tanto do programador quando do cliente. Tem o ANALISTA: profissional
responsável por captar reais necessidades dos stakeholders e não apenas seus desejos expressos, tendo profundo
conhecimento do negócio, formação ampla, apenas o conhecimento da área de desenv de sistemas não basta;
habilidades interpessoais e pensamento sistêmico; domínio de técnicas e ferramentas de modelagem, por exemplo a
UML.
PRINCÍPIO DA UNICIDADE: regras de negócio devem ser únicas; devem ser escritas de forma clara e explícita para
diminuir ambiguidade, e devem ser especificadas por pessoas com maior conhecimento, e as regras devem ser
gerenciáveis..

MODELAGEM PROCESSO DE NEGÓCIO COM UML e seus elementos

Diagrama de processo = diagrama de eriksson e penker; diagrama de atividades.
ELEMENTOS-
Recursos: representam os objetivos de uma organização, como pessoas, materiais e informações, que são usados,
consumidos refinados ou produzidos em um processo de negócio.
Processos: representam atividades executadas em uma organização;
Objetivos: representam o resultado que se deseja alcançar, as metas da organização.
Regras: representam os aspectos que restrigem algum aspecto do negócio e o conhecimento do negócio;
Eventos: representam a mudança de estado do negócio, um evento pode ser gerado por um processo que,inclusive,
pode estar fora do negócio e é recebido por um ou mais processos. OU SEJA, os processos estarão circulados por
esses elementos.
Definido na UML, o diagrama de atividade repreenta um fluxo de atividades que tem como objetivo atingir um
determinado objetivo, sendo muito semelhante ao fluxograma tradicional. Sendo utilizado para:
-modelagem de fluxo de trabalho: dá ênfase ao processo de negócio sob o ponto de vista dos atores do sistema.
-modelagem de operação: expõe a visão computacional da implementação de um caso de uso.

Principais elementos do diagrama de atividades: ponto de início, atividade, fluxo de controle e ponto de conclusão.

VISÕES DA UML
Cada diagrama da UML tem um propósito, representa algo p determinado publico alvo”. E lembre-se que cada
modelo são representações de uma parte do sistema sob algum ponto de vista, e no caso você usada o diagrama
com base no propósito do projeto.
VISÕES DA UML-
-visão de caso de uso: diagrama de casos de uso, diagrama de processo e diagrama de atividade.
-visão lógica: estrutura estática(diagrama de classe e de objeto). Estrutura dinâmica(diagrama de estado, de
sequência, de colaboração, de interação e de atividades.)
-visão de processo: usados para os mesmos diagramas da visão lógica, mas com ênfase na linha de execução do
sistema.
-visão de implementação: diagrama de componentes.
-visão de implantação: diagrama de implantação.

---------------------------------------- MÓDULO 4------------------------------------------------

VISÕES ESTRUTURAIS
Produz modelos que representam as necessidades do negócio, que são traduzidas nas funcionalidades de um
sistema de software. No entanto, no projeto de software, necessitamos de mais do que especificar as
funcionalidades, necessita especificar os proelmas q serão resolvidos. Para construir um software precisa de um
projeto, para não correr tantos riscos de ter requisitos funcionais e não funcionais implementados ou implementados
de maneira incorreta, dando resultado: baixa qualidade, retrabalho, aumento do custo e do prazo.
Quando fala de paradigmas da orientação a objetos, ou seja, de sistemas de software orientado a objetos, os
componentes do sistema podem ser interpretados como objetos e comunicação entre esses objetos e a comunicação
entre os objetos visa à execução de uma forma determinada tarefa, sendo que a representação desses objetos e à
relação entre eles dá-se o nome de visão estrutural, que basicamente é a representação da estrutura dos objetos e
da relação entre eles. O PARADIGMA DA ORIENTAÇÃO A OBJETOS é uma forma de se desenvolver um sistema de
software que o enxerga como um conj de componentes que interagem entre si para resolver um determinado
problema, sendo que cada componente dá se o nome do objeto. A motivação da abordagem orientada a objetos se
dá pela tentativa de aproximar o desenvolvimento de software daquilo que acontece no mundo real.

REPRESENTAÇÃO DA ESTRUTURA ESTÁTICA-

A melhor maneira de representar eles e usando o modelo de classes, sendo 3 modelos de classe utilizados: modelo
de classe de domínio; modelo de classe de especificação e modelo de classe de implementação.
OBJETO: é um elemento do mundo real que possui relevância para a solução de um determinado problema e contém
atributos e métodos. Objetos possuem características (atributos) e objetos realizam ações(métodos).
Classe de objetos: pode ser definida como um grupo de objetos com as mesmas propriedades (atributos),
comportamento (operações), relacionamentos e semântica. Ex: carro, possui características(atributos- cor,
quantidade de portas, potência.) ações(métodos – acelerar, frear). Quando os atributos passam a ter valor dizemos
que o objeto possui um estado, ex: cor: vermelha.
OBJETO X CLASSE
Classe é uma especificação de um objeto, e na classe é onde estão descritos os atributos(características) e
ações(métodos) de um objeto. E dizemos também que um objeto é uma instância de uma classe.
Encapsulamento: significa deixar visível apenas o que é necessário para a comunicação entre dois objetos (ex: em
um tv, todos os comportamentos estão visíveis ao user ?)
Abstração: é um dos principais conceitos aplicado à resolução de problemas, e ligado à nossa capacidade de
selecionar determinados aspectos do problema e isolar o que é importante para algum propósito e dar ênfase no que
é necessário.
Herança: + importante e + usado no paradigma da orientação a objetos, ou seja um objeto pode herdar carcterísticas
e comportamentos(atributos e métodos) de outro objeto.

RELAÇÃO ENTRE OBJETOS

Agregação/composição: é quando um objeto faz parte de outro (ex: carro/motor- a diferença de agregação está no
cilo de vida dos objetos)
Associação: apenas mostra que um objeto pode se relacionar com outro(ex: cliente/produto-compras).
Dependência: é quando um objeto depende de outro p executar um determinado comportamento (ex: leitora de
cartão/cartão).

MODELO DE CLASSE DE DOMÍNIO: representa os objetos ou classes inerentes ao domínio do problema que
queremos resolver, deixando de lado, nessa visão, detalhes tecnológicos da solução do problema.

VISÃO ESTRUTURAL ESTÁTICA:DIAGRAMA DE CLASSES

Visão estrutural dinâmica ou também chamada de visão comportamental tem como objetivo representar a interação
dos objetos para atingir um determinado objetivo = realização de casos de uso. IMPORTANTE: o modelo estrutural
dinâmico é originado do modelo estático, ou seja, não existe comportamento dinâmico que não tenha sido
representado nos diagramas de classe ou de objeto. Qualquer tipo de interação no modelo dinâmico acarreta
mudança no estático e vice versa.

ASPECTOS IMPORTANTES PARA A MODELAGEM DE ASPECTOS DINÂMICOS: visibilidade de atributos e

métodos(público, privado, protegido). E polimorfismo.
A comunicação entre objetos se dá por meio da troca de mensagens. Na UML utilizamos principalmente o diagrama
de sequência para representar essa interação.