Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Design Description Language
Transcript of Design Description Language
Design 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 Software
The 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?
The 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
Support analytical capabilities or provide quick generating prototype implementations
EXAMPLES OF Design Description Language:-
LePUS3 and Class-Z
Design Description Language
By Group 7
A Super Set of ADL
The 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 templates
ADLs 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 ADL
ADLs 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 systems
Negative elements of ADL
There 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 analysis
LePUS3 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.
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
Visualization (only LePUS3): To allow tools to reverse-engineer legible Codecharts from plain source code modelling their design
Pattern verification: To allow tools to determine automatically whether your program implements a design pattern
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 them
What can be modelled with LePUS3 ?
(Above: collections and iterators in java.util)
Object-oriented design patterns
(Above: Iterator pattern)
Object-oriented application frameworks
(Above: Java RMI)