22-05-2014, 04:40 PM
Design Document Version 1.1--- A casestudy on designing embeddedsystems using the UM
1370328496-SDDTemplatenew (1).docx (Size: 194.17 KB / Downloads: 12)
Disclaimers
The information contained in this document is the proprietary and exclusive property of XXX except as otherwise indicated. No part of this document, in whole or in part, may be reproduced, stored, transmitted, or used for design purposes without the prior written permission of XXX.
The information contained in this document is subject to change without notice.
The information in this document is provided for informational purposes only. XXX specifically disclaims all warranties, express or limited, including, but not limited, to the implied warranties of merchantability and fitness for a particular purpose, except as provided for in a separate software license agreement.
Privacy Information
This document may contain information of a sensitive nature. This information should not be given to persons other than those who are involved in the ProjectName project or who will become involved during the lifecycle
1 Introduction
The Unified Modelling Language [BJR1, BJR2], provides a standardised notation to express object-oriented software analysis and design [CY90, MO92, SS95]. UML diagrams are able to model complex software systems including real-time embedded systems. However, UML is not a software process. UML does not specify the different stages of the development of a software project. The UML standard specifies a notation for several different diagrams, but it does not describe how to create and apply each diagram. [Dou98] presents a methodology for building embedded systems using the UML notation and object-oriented analysis and design techniques. This document describes the object-oriented design and implementation of a digital sound recorder, or Dictaphone, using the UML notation and the method described by Douglass. There are several digital sound recorders commercially available in the market. The model described here has been designed following the specifications of a commercial product from a well know manufacturer. These requirements are described in the second section of this document. The third section discusses the object model of the system and presents the main class diagram. The fourth section continues the object-oriented analysis but focusing in the internal behaviour of each object. The fifth section deals with the architectural design. We show the hardware architecture of the sound recorder and the concurrency model, where we assign each object to an execution thread. The design continues defining the collaborations between the different objects. This is done in section number six, where design patterns [GHJV95] are used to glue together the classes defined in the analysis phase. The most specific design issues are discussed in the section number seven. Finally, The eighth section discusses the implementation. We have implemented the software in the C++ programming language and built the hardware platform to run the code using a 32 bits RISC embedded processor.
Identification
Include a full identification of the system and software to which this document applies, including, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
Identify all standards (ANSI, ISO, IEEE, etc) that apply to the design document.
Scope
Describe the scope of the design document (and also what is outside of scope); scope of the requirements definition effort and outline the requirements elicitation team, e.g. users, customers, and developers
Relationship to Other Plans
Describe this document’s relation to other plans, such as:
• Program Management Plan
• Configuration Management Plan
• Software Quality Assurance Plan
References
List any documents that are related to the document, e.g. technical specifications and administration guides. Include the version number, if appropriate.
Scope of Work
In this chapter, describe the business and technical requirements that the customer has requested. Outline the scope of work, including the inputs, processing functionality, and outputs.
System-wide design decisions
Provide a functional decomposition chart detailing the functions performed by the systems and the information flow among system functions.
Use a Physical Data Model to illustrate the implementation of the data of the Logical Data Model, e.g., message formats, file structures, physical schema.
Divide this section into paragraphs as required to present system-wide design decisions, e.g. system behavioral design.
System Functions
Provide an overview of the system’s main functionality. Include a graphical representation if appropriate.
Similar System Information
Describe the relationship of the system with any other systems. Confirm if it is stand-alone solution or a component of a larger system. In the latter case, outline the relationship among the systems.
User Characteristics
Describe the features of the user community, and their proficiency with software systems etc.
Data Dictionary
Outline the data elements to be included in the physical schema. Each data element requires the following information:
• Data Element Name
• Data Format/Length
• Data Type
• Definition
• Specifications
• Synonyms
• User Defined Name
• User Synonyms
Data Migration and Transformation
Provide a data migration map and data migration/transformation plan.
Outline the various options for managing ‘bad data.’
Describe the process to move existing data and transform/migrate it into the correct values/format of the new application.