1 / 18

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

Validating Integration Requirements. 8:15 AM Tuesday September 15, 2009 Karl Frank, Point of Contact for Constellation Projects. Diagrams for illustrative purposes only. Scope. Software components Documents explicitly labeled as Integration Requirement Docs

annasjohnson
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Validating Integration Requirements 8:15 AM Tuesday September 15, 2009 Karl Frank, Point of Contact for Constellation Projects Diagrams for illustrative purposes only.

  2. 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

  3. 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

  4. System Level Comm Diagram

  5. 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.

  6. Abstract Comm Diagram

  7. 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

  8. 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

  9. 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

  10. 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

  11. Completeness Audits Which components require? Which provide? That service? Ensure there is a provider for every required service • A particular service • Ensure that there is a consumer for every provided service UML model (not diagrams) can automate queries on model database to discover gaps and mismatches

  12. Consistency Audits Exactly how does the provider define Exactly what data does the consumer expect? A way to specify that exactly the same details are supported on both sides of the interface • Detailed specifications of data is supported, not just names like “Engine Status”

  13. Supports Elaboration Simple view Switch to detailed view Of the same interface, showing details of the services offered • Without “drawing” a new diagram, continuous evolution of more details in the same model

  14. 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

  15. 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!

  16. Differentiating Hardware and Software Software Component Notation FSW: Flight Software ECU: Engine Control Unit Hardware Deployment Notation

  17. Combined View of HW and SW components

  18. Notation Basics FSW: Flight Software Ports: Represent Interaction Points and control what kind of service or data is made public at that point by the component RIU: remote interface unit

More Related