Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start 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

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Design Description Language

No description
by

Danish Sinha

on 28 September 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Design Description Language

What do you mean by
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 satisfied 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 requirements
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.
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

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 ?
Object-oriented programs
(Above: collections and iterators in java.util)
Object-oriented design patterns
(Above: Iterator pattern)
Object-oriented application frameworks
(Above: Java RMI)
Full transcript