8:15 AM Tuesday September 15, 2009Karl Frank, Point of Contact for Constellation Projects

Validating Integration Requirements

Diagrams for illustrative purposes only.

Scope• Software components

– Documents explicitly labeled as Integration Requirement Docs

– Software Component Requirement Docs containing specifications for software interfaces

• We don’t validate hardware interfaces– Software interfaces: concept here is

fundamentally different. Requirements for data consistency, for example, in software interfaces, are special

Evolution of an approach• First iterations of behavior modeling included

communication diagrams representing interactions among systems shown as objects

• Showed scenarios of message exchange (requests for services, broadcasts of status data, etc.) passed between systems – as well as physical exchanges: Breathing Air, Power

• Messages descriptive text• Particular sender owned messages,

represented as labeled lines between objects

System Level Comm Diagram

Specialized Comm Diagrams• Next iterations of communication diagrams

representing interactions between systems concealed the actual destinations in the interest of platform independent view

• Messages still descriptive text on lines, not first-class model elements

• As a view of an interaction, still owned by the sender, and not re-assignable as services to another interface of another component.

Abstract Comm Diagram

Goal: move to service contract

• Particular component ownership of services of no interest, indeed an obstacle because a design specific feature

• Desire to use design-by-contract concepts• Specify Interfaces without hard commitment

to what component provides the interface• Model services in a way that allows moving

them around in the model and associating them with design-by-contract properties

UML interface concept provides that!

• Early proposal to use a text document with a common template, for defining interfaces and service contracts

• UML 2 already provide these concepts– Not surprising since the language was

designed to support software engineering needs.

– Interfaces and services with contracts maintained in the model

– Reassign by drag and drop as needed

Model as Database of Interfaces• Drag desired

interface onto diagrams as needed, associate with any component

• Move selected services between interfaces, without having to redefine their associated contracts

Name alone doesn’t tell if an interface will meet expectations

A Control that actually ignites an engine is very different from status query that

reports if its running

Completeness Audits

Which components require?• A particular service• Ensure that there is a

consumer for every provided service

Which provide?• That service?• Ensure there is a provider

for every required service

UML model (not diagrams) can automate queries on model database to discover gaps and mismatches

Consistency AuditsExactly how does the provider define• Detailed specifications of

data is supported, not just names like “Engine Status”

Exactly what data does the consumer expect?• A way to specify that

exactly the same details are supported on both sides of the interface

Supports Elaboration

Simple view• Without “drawing” a new

diagram, continuous evolution of more details in the same model

Switch to detailed view• Of the same interface,

showing details of the services offered

Beyond Behavior• Interaction a UML

behavior concept, represented in sequence and communication diagrams, adapted to show temporal sequences, aka scenarios

• UML provides static structure and data type modeling, adapted to represent architectural interfaces and to specify data requirements

Advantages of Diagram Choice

• Differentiates software architecture components from hardware architecture on which it is deployed.

• Distinguishes interfaces provided from interfaces required• Can show the services offered in an interface

FSW: Flight Software J2X ECU: Engine Control Unit

Spotting inconsistent assignment of a command to a query interface!

Software Component Notation

Hardware Deployment Notation

FSW: Flight Software

ECU: Engine Control Unit

Differentiating Hardware and Software

Combined View of HW and SW components

Ports: Represent Interaction Points and control what kind of service or data is made public at that point by the componentRIU: remote interface unit

FSW: Flight Software

Notation Basics