# t_attribute

Notes:
Vyjadøuje množství, kolikrát lze použít políèko trávy k pastvì.


Notes:
Pole idèek pøedmìtù, potøebných pro stavbu


Notes:
Udává množství spotøeby výdrže za sekundu. Ovlivìno sílou a odolností.


Notes:
Musí být pole, aby bylo možné vytvoøit komplexní úkoly


Notes:
0 = nahoru
1= dolù
2 = doleva
3 = doprava


# t_efforttypes

Notes:
The construction phase is concerned with designing and building the components necessary to implement the system as specified.


Notes:
The elaboration phase is concerned with refining the system specification, setting up project infrastructure and agreeing on the body of work to be completed.


Notes:
The Transition phase revolves around the implementation of the project and the acceptance testing carried out by the end user


# t_genopt

Option:
_AFX_NO_DEBUG_CRT;_AFX_NO_OCC_SUPPORT;_AFX_OLD_EXCEPTIONS;_AFX_PACKING;_AFXDLL;_DEBUG;_MSC_VER;_UNICODE;AFX_CDECL;AFX_COMDAT;AFX_DATA;AFX_DATADEF;AFX_NOVTABLE;AFXAPI;APICALL;BEGIN_INTERFACE_PART ^ END_INTERFACE_PART;BEGIN_PARAM_MAP ^ END_PARAM_MAP;CONTROLLER_API;DECLARE_DYNAMIC();DECLARE_DYNCREATE();DECLARE_INTERFACE_MAP();DECLARE_MESSAGE_MAP();defined();PASCAL;SWLAPI;WINAPI;


# t_glossary

Meaning:
A defined period of time whereby performance  reports may be extracted. (normally 4 week periods).


Meaning:
A relationship between two or more entities. Implies a connection of some type - for example one entity uses the services of another, or one entity is connected to another over a network link.


Meaning:
A logical entity encapsulating data and behavior. A class is a template for an object - the class is the design, the object the runtime instance.


Meaning:
The component model provides a detailed view of the various hardware and software components that make up the proposed system. It shows both where these components reside and how they inter-relate with other components. Component requirements detail what responsibilities a component has to supply functionality or behavior within the system.


Meaning:
A person or a company that requests An entity to transport goods on their behalf.


Meaning:
A view of the proposed hardware that will make up the new system, together with the physical components that will execute on that hardware. Includes specifications for machine, operating system, network links, backup units &etc.


Meaning:
A model of the system as it will be physically deployed


Meaning:
A relationship between two use cases in which one use case 'extends' the behavior of another. Typically this represents optional behavior in a use case scenario - for example a user may optionally request a list or report at some point in a performing a business use case.


Meaning:
A relationship between two use cases in which one use case 'includes' the behavior. This is indicated where there a specific business use cases which are used from many other places - for example updating a train record may be part of many larger business processes.


Meaning:
A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example creating a train, modifying a train and creating orders are all Use Cases.
Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behavior.
Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work.


# t_html

Template:

Untitled

Enterprise Architect


Use Case Report:
#NAME#
Author:
#AUTHOR#
Date Prepared:
#DATE#
Comments:
#COMMENT#
 




Template:
#ObjectDetail#
#ITEM#
#TYPE#
#NOTE#
		#ROWS#


Template:
Enterprise Achitect Diagram Template
#PROJECT#


#REPORT#:
#NAME#
Package:
#PACKAGE#
Author:
#AUTHOR#
Date:
#DATE#
Comments:
#COMMENT#
 



Entity List



#ENTITIES#


End of Report

#IMAGEMAP#	


Template:
Type:
#TYPE#
Stereotype:
#STEREO#
Author:
#AUTHOR#
Date:
#DATE#
Package:
#PACKAGE#
Notes:
#NOTE#


Template:
#ITEM#
#TYPE#
#NOTE#


Template:
#NAME#
#TYPE#
#COMPLEX#
#PACKAGE#


Template:
Untitled

Enterprise Architect : Use Case Metrics Report 




Use Case Metrics


Use Case : Root Package
#NAME#
Date Prepared:
#DATE#
Unique Use Case Points
#UUCP#
Total Package Estimate (hours)
#ESTIMATE#

 

Estimate Summary

  
Use Case Points (UCP) =
#UCPCALC#
#UCPRESULT#
Work Effort (hours) =
#EFFORTCALC#
#EFFORT#
 

View
Technical Complexity Summary

Environmental Factors Summary

Unique Use Cases and Actors

Technical Complexity Details

Environmental Factors Detail 

 

Technical Complexity Factors

  
Factor
Weight
  
Unadjusted TCF Value (UTV)
#UTV#
TCF Weight Factor (TWF)
#TWF#
TCF Constant (TC)
#TC#
Technical Complexity Factor (TCF) = TC + (TWF*UTV)
#TCF#
 

Environmental Factors

  
Factor
Weight
  
Unadjusted ECF Value (UEV)
#UEV#
ECF Weight Factor (EWF)
#EWF#
ECF Constant (EC)
#EC#
Environmental Complexity Factor (ECF) =
EC + (EWF*UEV)
#ECF#
 

Unique Use Cases and Actors

  
Name
Type
Complexity
Package
    #UUCAA#  
 

 


Technical Complexity Factors
#TCFDATA# 
 

 


Environmental Complexity Factors
#ECFDATA# 
 

 





Template:
#CFID_TITLE#
#CFID_NAME#
#CFID_WEIGHT#
#CFID_VALUE#
#CFID_EXVALUE#


# t_metrictypes

Notes:
Measures such as function points, SLOC, scenarios, test cases.


# t_operation

Notes:
Vrací true, když je vozík na platformì u domu.


Notes:
Vrací true když má hráè dostatek XP pro postup na další úroveò.


Notes:
Vrací true, když je splnìno požadované množství.


Notes:
Konstruktor pro vytvoøení šablony úkolu.


Notes:
Musí být pole, aby bylo možné vytvoøit komplexní úkoly


# t_projectroles

Description:
Define and model the application structure


Notes:
Define and communicate application architecture


# t_requiretypes

Description:
System will display in a specified format

Notes:
Information will be displayed in a particular way


Notes:
The system must meet some performance criteria


Notes:
The system will allow the user(s) to print out some artifact as required by the specification.


Notes:
The system will have the facility to produce a report as required


Notes:
The system will validate a specific rule as supplied in the business requirements


# t_rtf

Template:
#TEXT#


Template:
#TEXT#


Template:


Template:
#INDENT#Figure 1 : #FIGURE#


Template:


Template:
Type: #TYPE#
Status: #STATUS#
Package: #PACKAGE#
Details: #DETAILS#
#NOTE#


Template:
#TEXT#


Template:
Method Type Notes


Template:
#TYPE# Description
#NOTE#


Template:
#ATTRIBUTE# #TYPE# #NOTES#


Template:
#TEXT#


Template:
#METHOD# #TYPE# #SCOPE#


Template:
Attribute Type Notes


Template:


Template:


{\info{\author gsparks}{\operator gsparks}{\creatim\yr2000\mo3\dy29\hr21\min45}{\revtim\yr2000\mo3\dy29\hr22\min14}{\version11}{\edmins2}{\nofpages1}{\nofwords0}{\nofchars0}
{\*\company Sparx Systems}{\nofcharsws0}{\vern113}}\margl1080\margr1080\widowctrl\ftnbj\aenddoc\hyphcaps0\formshade\viewkind4\viewscale100\pgbrdrhead\pgbrdrfoot \fet0\sectd \linex0\headery709\footery709\colsx709\endnhere\sectdefaultcl {\*\pnseclvl1
\pnucrm\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl2\pnucltr\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl3\pndec\pnstart1\pnindent720\pnhang{\pntxta .}}{\*\pnseclvl4\pnlcltr\pnstart1\pnindent720\pnhang{\pntxta )}}{\*\pnseclvl5
\pndec\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl6\pnlcltr\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl7\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}{\*\pnseclvl8\pnlcltr\pnstart1\pnindent720\pnhang
{\pntxtb (}{\pntxta )}}{\*\pnseclvl9\pnlcrm\pnstart1\pnindent720\pnhang{\pntxtb (}{\pntxta )}}


Template:
#TEXT#


Template:
#TEXT#


Template:


Template:
#TEXT#


# t_rtfreport

Intro:
The system architecture model defines the overall hardware/software architecture used to implement the system.


Intro:
The logical model is made up of the Domain Model - a high level model of business objects and relationships between objects suitable for analysing the business process, and the class model - a rigorous model of classes and their inter-relationships, suitable for building a software product.


Intro:
The component model provides a detailed view of the various hardware and software components that make up the proposed system. It shows both where these components reside and how they inter-relate with other components. Component requirements detail what responsibilities a component has to supply functionality or behaviour within the system.


Intro:
The Deployment View provides a detailed model of the way components will be deployed across the system infrastructure. It details network capabilities, server specifications, hardware requirements and other information related to deploying the proposed system.


Intro:
The Development Environment model provides a detailed view of the various hardware and software components that are involved in the development of the application. It shows both where these components reside and how they inter-relate with other components. Component requirements detail what responsibilities a component has to supply functionality or behaviour within the system.


Intro:
The DRP model provides an overview of the proposed Disaster Recovery Procedures for the FMS application.


Intro:
The Dynamic Model provides a view of business processes that impact the proposed system. It shows how actors carry out high level business tasks to meet business demands. Business processes that will be performed by the proposed system will be ultimately implemented by the Use Cases detailed in the Use Case model.


Intro:
The Release Management model provides a detailed view of the various hardware and software components that are involved in the management of software versions released into the proposed production environment. It shows both where these components reside and how they inter-relate with other components. Component requirements detail what responsibilities a component has to supply functionality or behaviour within the system.


Intro:
The Use Case Model describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example creating a train, modifying a train and creating orders are all Use Cases.
Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behaviour.
Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work.


# t_scenariotypes

Notes:
Path of execution that includes exceptional conditions.


Notes:
The standard execution path with no exceptions


# t_stereotypes

Description:
A classifier whose instances represent a flow


Description:
Source class will be notified when an event occurs in target


Description:
A worker who directly interacts with actors outside the system


Description:
Passive class accessed and manipulated by workers


Description:
A worker that interacts with other workers and entities inside the system.


Description:
An abstraction of a human that works within the system.


Description:
Contains business process objects, work units, organization units and relationships


Description:
Subsystem corresponding to an organizational unit of the actual business


Description:
Specifies an element that is at the system boundary (e.g.. User Interface)


Description:
A class that represents a client based web page


Description:
Specifies an element that controls the work and lifetimes of other objects


Description:
Specifies a persistent element mainly concerned with managing its own state


Description:
An event may be thrown or caught by operation


Description:
A class that represents a html frame set


Description:
Implementation of a class in some programming language


Description:
A collection of operations that specify a service of a class or component


Description:
A classifier whose objects are all children of a given parent


Description:
A library of subroutines/functions for web pages


Description:
A class that represents a server based web page


Description:
Specifies an asynchronous stimulus communicated amongst instances


Description:
The classifier is a stereotype that may be applied to other elements


Description:
A class that represents a database table


Description:
A classifier whose instances represent a lightweight flow of control


Description:
An abstract class specifying the structure but not implementation of a set of objects


Description:
A class whose attributes and operations are all class-scoped


Description:
A classifier whose objects are all classes


Description:
Specifies a desired feature, property or behavior of system


Description:
Specifies a contract by or an obligation of a class


Description:
Component represents a document containing source code


Description:
A component that represents a database table


Description:
Constrain must always hold for associated element


Description:
A constraint must hold after the invocation of an element


Description:
A constraint that must hold before an element is invoked


Description:
Public contents of target are accessible to namespace of source


Description:
Source instantiates target template using given parameters


Description:
Source is given special visibility of target


Description:
Public contents of target are imported into source namespace


Description:
The source object is an instance of the target


Description:
Operations on the source class create instances of the target class


Description:
Source is at a finer degree of abstraction than source


Description:
The target is an historical ancestor of source


Description:
The semantics of the source depend on the public part of the target


Description:
Child inherits implementation of parent but does not support its interfaces


Description:
A GUI element that forces user selection


Description:
A GUI element for grouping other controls


Description:
A List of Information with an expandable text field


Description:
A List of Information with a tree structure


Description:
Corresponding object is visible because of enclosing scope


Description:
The corresponding object is visible in local scope


Description:
The corresponding element is visible because it is a parameter


Description:
The corresponding object is visible because it is the dispatcher


Description:
Target is same as source but later in time


Description:
Target is exact but independent copy of source


Description:
Contains analysis classes - entities, boundaries and control elements


Description:
Contains implementation subsystems and/or components and relationships


Description:
Specifies the services offered to the users


Description:
A class that represents a personal computer


Description:
A class that represents a storage device


Description:
A Check constraint to enforce domain integrity


Description:
A trigger which executes automatically when an UPDATE, INSERT, or DELETE statement is issued


Description:
A Unique constraint to enforce the integrity of a database automatically


Description:
Package is a view of another concrete package


Description:
A semantically closed abstraction of a system


Description:
A package serves as a proxy for the public contents of another package


Description:
A grouping of elements that constitute a specification of behavior offered by other contained elements


Description:
A package representing the entire system being modeled


Description:
Communication between actor and use case


Description:
Target use case extends the source at a given extension point


Description:
Source use case explicitly includes the behavior of target


# t_tcf

Description:
Response or throughput performance objectives


Description:
Special user training faciities are required


# t_umlpattern

Notes:
This pattern avoids coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. It chains the receiving objects and passes the request along the chain until an object handles it.


Notes:
This pattern encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.


Notes:
This pattern, given a language, defines a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.


Notes:
This pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.


Notes:
This pattern defines an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.


Notes:
This pattern, without violating encapsulation, captures and externalizes an object's internal state so that the object can be restored to this state later.


Notes:
This pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.


Notes:
This pattern allows an object to change its behaviour when its internal state changes. The object will appear to change its class.


Notes:
This pattern defines a family of algorithms, encapsulates each one and makes them interchangeable. It lets the algorithm vary independently from clients that use it.


Notes:
This pattern defines the skeleton of an algorithm in an operation, deferring some steps to subclasses. It lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.


Notes:
This pattern represents an operation to be performed on the elements of an object structure. It lets you define a new operation without changing the classes of the elements on which it operates.


Notes:
This pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.


Notes:
This pattern separates the construction of a complex object from its representation so that the same construction process can create different representations.


Notes:
This pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. It lets a class defer instantiation to subclasses.


Notes:
This pattern specifies the kinds of objects to create using a prototypical instance, and creates new objects by copying this prototype.


Notes:
This pattern ensures a class only has one instance, and provides a global point of access to it.


Notes:
This pattern decouples an abstraction from its implementation so that the two can vary independently.


Notes:
This pattern composes objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and compositions of objects uniformly.


Notes:
This pattern attaches additional responsibilities to an object dynamically providing a flexible alternative to subclassing for extending functionality.


Notes:
This pattern provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use.


Notes:
This pattern uses sharing to support large numbers of fine-grained objects efficiently.


Notes:
This pattern provides a surrogate or placeholder for another object to control access to it.


Notes:
This pattern converts the interface of a class into another interface that clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.


