No padrão IEEE / EIA 12207.1-1997, o que “notação por descrição” se refere?

5

O guia IEEE 12207.1-1997 (Processos de ciclo de vida do software - dados do ciclo de vida) possui uma lista de requisitos gerais de conteúdo para todos os documentos de descrição (seção 5.1, página 12). Isso inclui "notação para descrição" (bullet f). Isso apenas se refere a qualquer sistema ou estrutura que seja usado para a descrição (por exemplo, linguagens de design, diagramas, etc.), ou existe outro significado?

O padrão define o propósito de uma descrição como "Descreva uma função planejada ou real, design, desempenho ou processo", por isso é muito alto nível. O contexto específico em que preciso aplicá-lo é um documento de design de software. Temos um requisito do cliente para usar seções deste padrão IEEE, bem como outro documento, e estou montando um modelo que organize todos esses requisitos em uma única estrutura de documento.

    
por Kelly Tessena Keck 12.08.2015 / 21:44
fonte

1 resposta

5

A resposta curta à sua pergunta é, sim, esta "notação para descrição" está indicando que seus documentos de descrição incluem uma linguagem de design e informações suficientes para que um leitor entenda essa linguagem de design. Uma análise completa, baseada no Padrão IEEE IEEE 1016-2009 para Tecnologia da Informação - Design de Sistemas - Descrições de Design de Software, está abaixo.

A partir de 13 de agosto de 2015, o padrão atual para descrições de design de software é Padrão IEEE IEEE 1016-2009 para Tecnologia da Informação - Design de Sistemas - Descrições de Design de Software . Vou basear o resto desta resposta nesse documento e versão.

A definição de uma descrição de design de software (SDD), apresentada em 1016-2009, é:

An SDD is a representation of a software design to be used for recording information and communicating that design information to key design stakeholders.

Ao contrário das iterações anteriores de 1016, a versão de 2009 é muito favorável a várias metodologias de desenvolvimento. Por exemplo, o texto da revisão de 1998 foi muito inclinado para uma abordagem Big Design Up Front . As ideias de 2009 podem ser mais facilmente aplicadas a grandes abordagens iniciais de projeto, iterativas e incrementais, e até de engenharia reversa. Além disso, não exige um formato - muitos padrões IEEE mais antigos para engenharia de software são voltados para documentos em papel. O conteúdo do documento 1016-2009 pode ser aplicado a "documentos em papel, bancos de dados automatizados, ferramentas de desenvolvimento de software ou outras mídias".

Em 1016-2009, um SDD contém 1 ou mais visualizações de projeto. Cada visão de design é governada por um ponto de vista de design, que é enquadrado por uma ou mais preocupações de projeto. Um ponto de vista de design também define um ou mais elementos de design, que são expressos em uma determinada linguagem de design.

Os seguintes são experts da Seção 2 Definições que se aplicam a estes termos:

3.2 design concern: An area of interest with respect to a software design.

3.4 design element: An item occurring in a design view that may be any of the following: design entity, design relationship, design attribute, or design constraint.

3.12 design view: A representation comprised of one or more design elements to address a set of design concerns from a specified design viewpoint.

3.13 design viewpoint: The specification of the elements and conventions available for constructing and using a design view.

Tudo isso significa que você começa a organizar seu SDD com base nas pessoas que usarão as informações contidas no SDD. Diferentes partes interessadas terão necessidades diferentes - considere administradores de rede ou de sistema que precisam saber sobre componentes distribuídos e protocolos de comunicação, administradores de banco de dados que precisam saber sobre as estruturas de dados para otimizá-los, equipe de garantia de qualidade que testará o software, engenheiros implementar e manter o software e assim por diante. Cada uma dessas pessoas tem diferentes preocupações que precisam ser capturadas no SDD. Essas preocupações serão usadas para enquadrar vários pontos de vista.

A Tabela 1 em 1016-2009 fornece vários exemplos de pontos de vista de design. Ele identifica 12 pontos de vista de design diferentes, mas não há indicação de que essa seja uma lista abrangente nem é necessária para todos os projetos. Alguns desses pontos de vista são um ponto de vista de contexto, um ponto de vista de informações, um ponto de vista de interação, um ponto de vista de dinâmica de estado e um ponto de vista de algoritmo. Para cada ponto de vista, a tabela também fornece exemplos de preocupações de projeto. Como exemplo, o ponto de vista de informações é usado para tratar de questões relativas a informações persistentes enquanto o ponto de vista do algoritmo fornece lógica processual e o ponto de vista lógico captura estruturas estáticas (classes, interfaces) e uso de tipos e implementações (classes, tipos primitivos). >

Depois de identificar os pontos de vista, você define os elementos de design que são usados para demonstrar esse ponto de vista, usando uma linguagem de design. Os elementos de design apropriados dependem do ponto de vista. Por exemplo, um elemento de design em um ponto de vista de dinâmica de estado seria eventos, estados, transições, atividades, gatilhos e assim por diante. Em um ponto de vista de algoritmo, os elementos de design seriam atributos, dados e etapas de processamento. Em um ponto de vista de informações, os elementos seriam tipos e classes de dados, formatos e estruturas de armazenamento de dados e mecanismos de acesso.

Depois de definir seus elementos de design, você os representa em uma linguagem de design. 1016-2009 não requer nenhuma linguagem ou notação específica. Eles listam vários exemplos - os tipos de diagramas UML apropriados (se houver) são frequentemente listados como exemplos para cada ponto de vista. No entanto, o padrão também menciona fluxogramas e pseudocódigo como exemplos para os pontos de vista do algoritmo ou diagramas de relação de entidade para o ponto de vista da informação. Em uma nota na Seção 4.9 Design Languages, o padrão indica que linguagens padronizadas de design (IDEF0, IDEF1X, UML, Vienna Definition Language) são melhores do que linguagens estabelecidas sem uma definição formal (máquinas de estado, autômatos, tabelas de decisão, diagramas de Warnier, Jackson Structured Design, modelos HIPO). No entanto, o autor é livre para escolher qualquer linguagem de design apropriada.

    
por 13.08.2015 / 14:58
fonte