1995
DOI: 10.1155/1995/74543
|View full text |Cite
|
Sign up to set email alerts
|

Decomposition of Sequential Behavior UsingInterface Specification and Complementation

Abstract: Decomposition of system behavior along functional boundaries into interacting sequential components is a key step in top-down system design. In this paper, we present sequential decomposition, a method for factoring sequential components from a system specification based on interface specifications of the components. The resulting components can be independently synthesized, or realized using off-the-shelf components. We introduce interface specification language (ISL), based on finite-state machine semantics,… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
4
1

Citation Types

0
5
0

Year Published

1997
1997
2022
2022

Publication Types

Select...
2
1
1

Relationship

1
3

Authors

Journals

citations
Cited by 4 publications
(5 citation statements)
references
References 12 publications
0
5
0
Order By: Relevance
“…Parnas's framework, however, assumes that the starting point for decomposition consists of an architectural specification of the system, while our starting point is quite more abstract, as we assume that we are provided with a relational specification. Another related work is that of [RCJ95], which describes an approach for extracting sequential components from a system specification. Unlike, however, our work here, which starts from a highly abstract relational specification, the approach of [RCJ95] assumes that the system's specification is provided by means of an interface specification of the components.…”
Section: Related Workmentioning
confidence: 99%
See 1 more Smart Citation
“…Parnas's framework, however, assumes that the starting point for decomposition consists of an architectural specification of the system, while our starting point is quite more abstract, as we assume that we are provided with a relational specification. Another related work is that of [RCJ95], which describes an approach for extracting sequential components from a system specification. Unlike, however, our work here, which starts from a highly abstract relational specification, the approach of [RCJ95] assumes that the system's specification is provided by means of an interface specification of the components.…”
Section: Related Workmentioning
confidence: 99%
“…Another related work is that of [RCJ95], which describes an approach for extracting sequential components from a system specification. Unlike, however, our work here, which starts from a highly abstract relational specification, the approach of [RCJ95] assumes that the system's specification is provided by means of an interface specification of the components. Thus, this approach is more in the sense of a factorization rather then a decomposition.…”
Section: Related Workmentioning
confidence: 99%
“…Parnas's framework, however, assumes that the starting point for decomposition consists of an architectural specification of the system, while our starting point is quite more abstract, as we assume that we are provided with a relational specification. Another related work is that of [41], which describes an approach for extracting sequential components from a system specification. Unlike, however, our work here, which starts from a highly abstract relational specification, the approach of [41] assumes that the system's specification is provided by means of an interface specification of the components.…”
Section: Related Workmentioning
confidence: 99%
“…Another related work is that of [41], which describes an approach for extracting sequential components from a system specification. Unlike, however, our work here, which starts from a highly abstract relational specification, the approach of [41] assumes that the system's specification is provided by means of an interface specification of the components. Thus, this approach is more in the sense of a factorization rather then a decomposition.…”
Section: Related Workmentioning
confidence: 99%
“…Had a synchronization handshake simply been added to the formally derived implementation, a correctness proof would have been required to validate the newly imposed memory model. Although this kind of refinement has since been added to DDD (Rath, Choppella & Johnson 1995, Rath 1995, it remains a good example of the potential need for heterogeneous reasoning in support of ad hoc refinements. It is difficult to contemplate a general interaction between DDD and Nqthm that would maintain correctness in cases like this.…”
Section: Nqthm and Dddmentioning
confidence: 99%