PowerDesigner Models

PowerDesigner enables you to closely integrate the design and maintenance of your application's core data layers with your project requirements, business processes, OO code, XML vocabularies, and database replication information and to align these with your overall enterprise architecture and corporate standards. By providing you with a comprehensive set of models at all levels of abstraction, PowerDesigner helps you broaden the reach of your iterative design process to all aspects of your system architecture, from conception to deployment, and beyond.

The following types of PowerDesigner models are available:

Icon	Description
	A requirements model (RQM) helps you analyze any kind of written requirements and link them with users and groups who will implement them and with design objects in other models. You can use an RQM to represent any structured document (e.g. functional specification, test plan, business goals, etc.) and import and export hierarchies of requirements as MS Word documents. File extension: `.rqm` Backup: `.rqb`
	An enterprise architecture model (EAM) helps you analyze and document your organization and its business functions, along with the applications and systems that support them and the physical architecture on which they are implemented. File extension: `.eam` Backup: `.eab`
	A business process model (BPM) helps you identify, describe, and decompose business processes. You can analyze your system at various levels of detail, and focus alternatively on control flow (the sequence of execution) or data flow (the exchange of data). SAP® Sybase® PowerDesigner® supports Analysis, SOA, DFD, SAP® Solution Manager, BPMN (including for SAP NetWeaver®), and BPEL process languages, and process simulation through SIMUL8. File extension: `.bpm` Backup: `.bpb`
	A conceptual data model (CDM) helps you analyze the conceptual structure of an information system, to identify the principal entities to be represented, their attributes, and the relationships between them. A CDM is more abstract than a logical (LDM) or physical (PDM) data model. File extension: `.cdm` Backup: `.cdb`
	A logical data model (LDM) helps you analyze the structure of an information system, independent of any specific physical database implementation. An LDM has migrated entity identifiers and is less abstract than a conceptual data model (CDM), but does not allow you to model views, indexes and other elements that are available in the more concrete physical data model (PDM). File extension: `.ldm` Backup: `.ldb`
	A physical data model (PDM) helps you to analyze the tables, views, and other objects in a database, including multidimensional objects necessary for data warehousing. A PDM is more concrete than a conceptual (CDM) or logical (LDM) data model. You can model, reverse-engineer, and generate for all the most popular DBMSs. File extension: `.pdm` Backup: `.pdb`
	A data movement model (DMM) provides a global view of the movement of information in your organization. You can analyze and document where your data originates, where it moves to, and how it is transformed on the way, including replications and ETL. File extension: `.dmm` Backup: `.dmb`
	An object-oriented model (OOM) helps you analyze an information system through use cases, structural and behavioral analyses, and in terms of deployment, using the Unified Modeling Language (UML). You can model, reverse-engineer, and generate for Java, .NET and other languages. File extension: `.oom` Backup: `.oob`
	An XML model (XSM) helps you analyze an XML Schema Definition (.XSD), Document Type Definition (.DTD) or XML-Data Reduced (.XDR) file. You can model, reverse-engineer, and generate each of these file formats. File extension: `.xsm` Backup: `.xsb`
	A free model (FEM) provides a context-free environment for modeling any kind of objects or systems. You can use it to sketch simple visualizations or create entirely new forms of model by defining your own concepts and graphical symbols through an extension file. See The Free Model (FEM). File extension: `.fem` Backup: `.feb`
	The glossary model (GLM) helps you capture and organize the terminology to be used for naming your model objects. An administrator deploys the glossary, and users enable it in their models to provide autocompletion for object names and model checks to ensure compliance. The glossary appears in the Browser Glossary tab and updates are pushed to users each time they connect to the repository, or on demand. Only one glossary is permitted per repository. See The Glossary and Deploying an Enterprise Glossary. File extension: `.glm` Backup: `.geb`
	A multimodel report (MMR) is a PowerDesigner report that can document any number of models together and show the links between them. To create such a report, you must have at least one model open in the workspace, and you can add additional models at any time. See Reports. File extension: `.mmr` Backup: `.bmr`

PowerDesigner does not impose any particular software engineering methodology or process. Each company can implement its own workflow, defining responsibilities and roles, describing what tools to use, what validations are required, and what documents to produce at each step in the process.

A development team will comprise multiple user roles, each of whom will use different PowerDesigner models:

Business Analysts – define the architecture of the organization, the business requirements and high-level business flows, and may use:
- EAM - for providing a big picture of the organization, defining its structure, and analyzing high-level functions, processes, and flows. These architectural objects can be attached to implementation objects in any of the other models.
- RQM - for defining business requirements to be refined into technical requirements by Analysts and Designers.
- BPM - to define the high-level business process flows in existing and new systems, and to simulate business processes to improve productivity.
Data Analysts and Designers - map technical requirements to business requirements, and may use:
- OOM - to define use cases and map them to requirements.
- BPM - to write functional specifications and define more precisely the nature and details of each process, the application and its data structure.
- CDM - to provide a clear view of business data across all systems.
Database Administrators use the well-defined data structure to optimize, denormalize, and create the database, and may use:
- PDM - to represent a database running on a server with complete information on the structure of the physical objects, such as tables, columns, references, triggers, stored procedures, views, and indexes, and to generate to and reverse-engineer from scripts or a live database connection. By maintaining a PDM and a CDM, you can ensure that your analysis and design efforts are reflected exactly in your actual systems.
- LDM - which can act as a bridge between a CDM and a PDM, allowing you to resolve many-to-many and super/sub-type relationships, de-normalize your data structures, and define indexes, without specifying a particular RDBMS.
- DMM - to represent the replication of information from a source database to one or several remote databases.
Developers model the application, defining object structures and behaviors, and Object/Relational mappings, and may use:
- RQM - to write technical specifications.
- OOM - to represent objects and their interactions in UML, and to generate and reverse engineer OO code. Close integration with your BPM, CDM, and PDM can greatly simplify the maintenance and development of your system.
- XSM - to graphically model the complex structure of an XML file and to generate and reverse-engineer DTDs, and XSDs and link them to your PDM and OOM.
Testers will use the RQM, CDM, and other models, together with the design documents to understand how the application should work and how it is developed.