Modelagem de Software

1. Linguagens de Modelagem de Requisitos

1.1. projetada especificamente para modelar requisitos visualmente para fácil compreensão dos stakeholders executivo, de negócio e técnico.

1.2. Não é uma linguagem de modelagem teórica

1.3. É um conjunto de modelos projetado especificamente para modelar requisitos de software e facilmente aceito por stakeholders do negócio que normalmente são desafiados por modelos complexos

1.4. Modelos de Requisitos

1.4.1. São utilizados do começo ao fim no ciclo de vida de um projeto

1.4.2. São úteis para analisar, elicitar e validar requisitos com stakeholders, e transmitir requisitos aos desenvolvedores e testadores.

1.5. Linguagens de Modelagem

1.5.1. UML

1.5.1.1. É uma linguagem utilizada para especificar visualmente o projeto de sistemas de software. • É uma base razoável para modelagem de requisitos. • Seus modelos são voltados para modelar a estrutura da arquitetura do software. • Descreve o projeto técnico e arquitetura de um sistema. • É adaptado para modelar requisitos, focados nos benefícios do negócio, ações do usuário e regras de negócio.

1.5.2. RML

1.5.2.1. Projeto com a sintaxe mais simples possível que permite ao modelo transmitir a informação necessária. • Fornece uma estrutura sintática e semântica consistente para ser utilizado por stakeholders do negócio para analisar e entender os modelos no projeto. • A linguagem é fácil de aprender e usada para todo o time: stakeholders do negócio, desenvolvedores e testadores.

1.6. Requisitos

1.6.1. -O que precisa ser feito.

1.6.1.1. Requisitos Funcionais

1.6.1.1.1. comportamento ou capacidade que a solução pode fornecer independentemente de quaisquer qualificadores.

1.6.1.2. requisitos não funcionais

1.6.1.2.1. qualquer requisito que não é funcional.

1.6.1.3. Requisitos de regras de Negócio

1.6.1.3.1. representa uma declaração condicional que modifica o requisito funcional.

1.7. Categorização de modelos

1.7.1. Modelos de Objetivos

1.7.1.1. • Descrevem o valor do negócio do sistema. • Prioriza características e requisitos baseados nesses valores. • Identifica os problemas que precisam ser solucionados (durante a implementação). • Refina o escopo.

1.7.2. Modelo de Pessoas

1.7.2.1. • Descreve os stakeholders do sistemas, seus processos de negócio e objetivos. • Quadro organizacional. • Identifica todos os stakeholders na organização. • Inclui quem usa, opera, constrói ou mantém o sistema. • Usuário que tem acesso ao sistema e a funcionalidade que regularmente usam. • Determinar como eles interagem com o sistema

1.7.3. Modelo de Sistemas

1.7.3.1. • Sistemas existentes, interface de usuário, interação dos sistemas e comportamento. • Ecossistema: aplicações que participam em um ambiente multissistêmico.  Serviços, cloud (nuvens), mobile (móvel).  Miríade de sistemas e processos que interagem com o sistema que está sendo alterado.

1.7.4. Modelo de dados

1.7.4.1. • Ciclo de vida dos dados. • Como os dados são utilizados em relatórios para tomada de decisões. • Documenta o conjunto completo de objetos de dados do negócio e sua hierarquia. • Dados podem ser criados, atualizados, utilizados, copiados e excluídos.

2. Modelagem de Software

2.1. Modelo de contexto

2.1.1. Pode ser utilizado como instrumento de análise funcional que identificará: - os elementos externos que irão interagir com o sistema - O fluxo de informações existente entre o sistema e o ambiente externo - Os limites do sistema - os eventos do ambiente externo que impactam o sistema provocando alterações

2.2. Modelos de Interação

2.2.1. São os aspectos dinâmicos do sistema, são fluxo de dados trocados entre os elementos que compõem o sistema com o objetivo de realizar alguma ação: -Caso de uso -Diagrama de sequência

2.3. Modelos estruturais

2.3.1. representa a organização, a disposição e a ordem dos elementos essenciais que compõem o sistema: - Diagrama de Classes

2.4. Modelos Comportamentais

2.4.1. Representam o comportamento dinâmico do sistema , o que acontece, ou o que deve acontecer quando o sistema reponde a um estimulo: -Modelagem orientada a dados -Modelagem orientada a eventos

3. Modelagem de Sotware

3.1. Conceito

3.1.1. Um modelo pode realizar planos detalhados, assim como planos mais gerais com uma visão panorâmica do sistema. Pode incluir detalhes e componentes de grande importância e omite os componentes menores que não necessitam de representação em determinado nível de abstração. Na modelagem, podemos delimitar o problema que estamos estudando, dividindo-o em vários problemas menores, restringindo a atenção a um único aspecto por vez até chegar à solução. : http://www.linhadecodigo.com.br/artigo/1293/a-importancia-do-modelagem-de-objetos-no-desenvolvimento-de-sistemas.aspx#ixzz46shp3DSM

3.1.2. Um modelo de software traduz a realidade, abstraindo alguns detalhes e focando outros, conforme a perspectiva de visçao e entendimento desejado

3.2. Objetivos da Modelagem

3.2.1. Conforme Pressman(2010,p145)

3.2.1.1. Descrever o que o cliente exige

3.2.1.2. Estabelecer a base para a criação de um projeto de software

3.2.1.3. Definir um conjunto de requisitos que possam ser validados quando o software for construído

3.2.2. Conforme Sommerville(2011,pg83)

3.2.2.1. Como forma de facilitar a discução sobre um sistema existente ou proposto

3.2.2.2. Como forma de documentar um sistema existente

3.2.2.3. Como uma descrição detalhada de um sistema, que pode ser usada para gerar uma implementação do sistema

3.3. Abstração

3.3.1. simplificando é seleção de características mais relevantes representada em linguagem gráfica que possibilita a visão do software em diferentes perspectiva :

3.3.1.1. Perspectiva externa

3.3.1.1.1. Modelagem ambiente do sistema

3.3.1.2. Perspectiva de Interação

3.3.1.2.1. Modelagem das integrações entre o sistema e o ambiente, ou entre os componentes

3.3.1.3. Perspectiva estrutural

3.3.1.3.1. considera a estrutura de dados processados pelo sistema

3.3.1.4. Perspectiva comportamenta

3.3.1.4.1. considera o comportamento dinâmico do sistema, sua reação aos eventos

3.4. Categorização de Modelos

3.4.1. Modelos de Objetivos

3.4.1.1. • Descrevem o valor do negócio do sistema. • Prioriza características e requisitos baseados nesses valores. • Identifica os problemas que precisam ser solucionados (durante a implementação). • Refina o escopo.

3.4.2. Modelos de Pessoas

3.4.2.1. • Descreve os stakeholders do sistemas, seus processos de negócio e objetivos. • Quadro organizacional. • Identifica todos os stakeholders na organização. • Inclui quem usa, opera, constrói ou mantém o sistema. • Usuário que tem acesso ao sistema e a funcionalidade que regularmente usam. • Determinar como eles interagem com o sistema.

3.4.3. Modelos de Sistemas

3.4.3.1. • Sistemas existentes, interface de usuário, interação dos sistemas e comportamento. • Ecossistema: aplicações que participam em um ambiente multissistêmico.  Serviços, cloud (nuvens), mobile (móvel).  Miríade de sistemas e processos que interagem com o sistema que está sendo alterado.

3.4.4. Modelos de dados

3.4.4.1. • Ciclo de vida dos dados. • Como os dados são utilizados em relatórios para tomada de decisões. • Documenta o conjunto completo de objetos de dados do negócio e sua hierarquia. • Dados podem ser criados, atualizados, utilizados, copiados e excluídos.