This is especially true for
embedded systems. Usually, the architecture is also the most stable part and
reveals core abstractions about the application elements and their behavior.
. Existing products, applications, features, and related manuals: These capture
the structure, behavior, and semantics, but unfortunately their complete
analysis is not always practical as it may be too time consuming to do an
exhaustive analysis of all the products. It is more convenient to select a
representative set of applications for more detailed inspection. Naturally, those
kinds of applications should be selected that have functionality closest to the
newly planned ones. It can also be that the applications and their features have
not yet been developed. Then, you may look into similar kinds of applications
in the same domain or inspect earlier generations or versions.
. Available speci?¬?cations: By analyzing existing descriptions of the features,
applications, or products, you can understand the structure of the domain and
translate it to a conceptual schema. Requirement documents are especially good
to raising the level of abstraction as they usually focus on the problem domain
rather than the implementation. Requirements also map the customer
terminology, making wider DSM use possible: customers can then better
read and check the models.
Pages:
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418