Design Description Language

Comments (0)

Transcript of Design Description Language

What do you mean byDesign Description Language ?Architecture description languages (ADLs) are used in several disciplines: system engineering, software engineering, and enterprise modeling and engineering.

The system engineering community uses an architecture description language as a language and/or a conceptual model to describe and represent system architectures.

The software engineering community uses an architecture description language as a computer language to create a description of a software architecture.Features of a good SoftwareThe design should be traceable to the analysis model. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisﬁed by the design model.

The design should be reviewed to minimize conceptual (semantic) errors. There is sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A design team should ensure that major conceptual elements of the design (omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax of the design model

Other Design features include Compatibility,Security,Portability and Maintainability.Design Description Language So what is the difference between architecture and design? Minimal requirementsThe language must:

Be suitable for communicating an architecture to all interested parties

Support the tasks of architecture creation, refinement and validation

Provide a basis for further implementation, so it must be able to add information to the ADL specification to enable the final system specification to be derived from the ADL

Provide the ability to represent most of the common architectural styles

EXAMPLES OF Design Description Language:-LePUS3 and Class-Z Design Description LanguageBy Group 7A Super Set of ADLThe process of defining an architecture may use heuristics or iterative improvements; this may require going a level deeper to validate the choices, so the architect often has to do a high-level design to validate the partitioning.

Architecture casts non-functional decisions and partitions functional requirements, whereas design specifies or derives functional requirements. ADLs have in common:Graphical syntax with often a textual form and a formally defined syntax and semantics

Features for modeling distributed systems

Little support for capturing design information, except through general purpose annotation mechanisms

Ability to represent hierarchical levels of detail including the creation of substructures by instantiating templatesADLs differ in their ability to:Handle real-time constructs, such as deadlines and task priorities, at the architectural level

Support the specification of different architectural styles. Few handle object oriented class inheritance or dynamic architectures

Support the analysis of the architecture

Handle different instantiations of the same architecture, in relation to product line architectures

Positive elements of ADLADLs are a formal way of representing architecture

ADLs are intended to be both human and machine readable

ADLs support describing a system at a higher level than previously possible

ADLs permit analysis and assessment of architectures, for completeness, consistency, ambiguity, and performance

ADLs can support automatic generation of software systemsNegative elements of ADLThere is no universal agreement on what ADLs should represent, particularly as regards the behavior of the architecture

Representations currently in use are relatively difficult to parse and are not supported by commercial tools

Most ADLs tend to be very vertically optimized toward a particular kind of analysisLePUS3 and Class-Z are formal object-oriented Design Description Languages.

They are formal specification lanaguges for modelling non-functional specifications representing the design of object-oriented class libraries, design patterns, and object-oriented application frameworks (What can be modelled with LePUS3).

LePUS3 diagrams ('Codecharts', or simply charts) are axiomatized as decidable statements in the first-order predicate logic.

LePUS3 is tailored for tool support in fully automated design verification (ie, checking conformance to Codecharts) and program visualization (ie design recovery from source code), as demonstrated by the the Two-Tier Programming Toolkit.Objectives LePUS3 and Class-Z are formal Design Description Languages tailored for the following purposes:Scalability: To model industrial-scale programs using small Codecharts with only few symbols

Automated design verifiability: To allow programmers to continuously keep the design in synch with the implementation

Abstraction in early design: To specify unimplemented programs without committing prematurely to implementation minutia

Genericity: To model a design pattern not as a specific implementation but as a design motif

Rigour: To be rigorous and allow software designers to be sure exactly what Codecharts mean and reason rigorously about themWhat can be modelled with LePUS3 ?Object-oriented programs(Above: collections and iterators in java.util)Object-oriented design patterns(Above: Iterator pattern)Object-oriented application frameworks(Above: Java RMI)