# 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_object

Name:
Pøidání uživatele mezi sledované uživatele


# t_objectscenarios

Notes:
Strucny popis:
Pøihlášení uživatele do systému.

Hlavni scenar:

	Uživatel vyplní pøezdívku a heslo, stiskne tlaèítko pøihlácit se.

	IF vyplnìné údaje souhlasí s databází, je uživatel pøihlášen.

	ELSE je zobrazena zpráva o chybnì vyplnìných údajích




Vystupni podminky:

	Uživatel je pøihlášen.


Notes:
Strucny popis:
Uživatel se registruje do systému.

Vstupni podminky:

	zadne




Hlavni scenar:

	Uživatel stiskne tlaèítko zaregistrovat se.

	Uživatel vyplní pøihlašovací formuláø a potvrdí ho.

	Provede se validace poskytnutých dat.

	IF validace v poøádku, uživatel je pøihlášen.

	ELSE uživatel je vyzván k opìtovnému vyplnìní formuláøe.




Vystupni podminky:

	Uživatel je zaregistrován.


Notes:
Strucny popis:
Uživatel shlédne základní informace o registrovaném uživateli.

Vstupni podminky:
zadne

Hlavni scenar:

	INCLUDE vyhledání uživatele

	Uživatel vstoupí na profilovou stránku nalezeného uživatele.

	Zobrazí se základní informace.




Vystupni podminky:

	jsou zobrazeny základní informace o uživateli.


Notes:
Strucny popis:
Uživatel vyhledává v databázi uživatelù.

Vstupni podminky:
žádné

Hlavni scenar:

	Uživatel vstoupí na stránku vyhledávání uživatelù.

	Uživatel vyplní informace pro vyhledávání [pøezdívka, jméno, pøíjmení].

	IF užvatel(é) nalezen, je zobrazen seznam nalezených uživatelù.

	ELSE je zobrazena informace o neúspìšném hledání.




Vystupni podminky:
Je nalezen požadovaný uživatel.


Notes:
Strucny popis:
Uživatel si prohlédne základní stránku skupiny.

Vstupni podminky:
žádné

Hlavni scenar:

	INCLUDE nalezení skupiny

	Uživatel vstoupí na stránku skupiny

	Systém zobrazí základní informace o skupinì.




Vystupni podminky:
Je zobrazeno základní info o skupinì.


Notes:
Strucny popis:
Uživatel vyhledává v databázi skupin.

Vstupni podminky:
žádné

Hlavni scenar:

	Uživatel klikne na odkaz vyhledávání ve skupinách.

	Uživatel vyplní jméno nebo èást jména hledané skupiny.

	IF skupina nalezena, systém vypíše seznam nalezených skupin.

	ELSE je zobrazena zpráva o neúspìšném hledání.





Vystupni podminky:
Je nalezna požadovaná skupina.


Notes:
Strucny popis:
Uživatel zakládá novou skupinu.

Vstupni podminky:
uživatel je pøihlášen.

Hlavni scenar:

	Uživatel klikne na možnost vytvoøit novou skupinu v profilu.

	Uživatel vyplní požadované informace o skupinì [název, popis...] a potvrdí je.

	IF skupina se stejným názvem již existuje, uživatel je vyzván ke zmìnì názvu skupiny.

	ELSE systém založí novou skupinu.





Vystupni podminky:
Nová skupina je založena a uložena v databázi.


Notes:
Strucny popis:
Uživatel zakládá podskupinu k existující skupinì.

Vstupni podminky:
uživatel je pøihlášený.

Hlavni scenar:

	Uživatel vstoupí na stránku skupiny, které chce vytvoøit podskupinu.

	Uživatel klikne na možnost pøidání podskupiny na kartì skupiny.

	Uživatel vyplní požadované informace o podskupinì [název, popis...] a potvrdí je.

	IF podskupina se stejným názvem již existuje, uživatel je vyzván ke zmìnì názvu podskupiny.

	ELSE systém založí novou podskupinu.




Vystupni podminky:
Je vytvoøena nová podskupina a je uložena v databázi.


Notes:
Strucny popis:
Uživatel prohlíží karty ostatních uživatelù.

Vstupni podminky:
uživatel je pøihlášený

Hlavni scenar:

	Uživatel stroupí na profilovou stránku jiného uživatele.

	Systém zobrazí veškeré informace o uživateli.





Vystupni podminky:
Jsou zobrazeny informace o požadovaném uživateli.


Notes:
Strucny popis:
Uživatel si prohlíží informace o skupinì

Vstupni podminky:
uživatel je pøihlášený

Hlavni scenar:

	Uživatel vstoupí na stránku skupiny

	Systém vyhodnotí, zda je uživatel èlen skupiny.

	IF je èlen zobrazí kompletní informace o skupine se všemi záložkami.

	ELSE zobrazí pouze základní informace o skupinì.





Vystupni podminky:
Jsou zobrazeny informace o požadované skupinì.


Notes:
Struèný popis:
Uživatel chce zaøadit jiního uživatele mezi své pøátele.

Vstupní podmínky:
Uživatel je pøihlášen

Scénáø:

	Uživatel vstoupí na profilovou stránku uživatele.

	Uživatel klikne na možnost sledovat uživatele.

	Systém ovìøí, zda již mezi nimi uživatel není.

	IF není, je mezi nì zaøazen.

	ELSE je zobrazena zpráva, že uživatel je již mezi pøáteli

	UC konèí




Výstupní podmínky:
Uživatel je zaøazen mezi uživatelovi pøátele.


Notes:
Struèný popis:
Uživatel se pøidává ke skupinì, která vyžaduje heslo pro vstup.


Scénáø:

	Scénáø zaèíná bodem 2 hlavního scénáøe.

	Uživatel je vyzván k zadání hesla.

	IF heslo odpovídá, uživatej je pøidán do skupiny.

	ELSE je zobrazena hláška o odepøení pøístupu.

	Následuje bod 4 hlavního scénáøe




Výstupní podmínky:
Uživatel je pøidán do skupiny.


Notes:
Struèný popis:
Uživatel se chce pøidat do skupiny.

Vstupní podmínky:
uživatel je pøihlášen

Scénáø:

	Uživatel vstoupí na stránku skupiny.

	Uživatel klikne na tlaèítko pøidat se ke skupinì.

	IF pro pøidání ke skupinì je vyžadováno heslo, zaèíná aleternativní scénáø.

	ELSE uživatel je pøidán ke skupinì.

	UC konèí




Výstupní podmínky:
Uživatel je pøidán mezi èleny skupiny.


Notes:
Struèný popis:
Uživatel chce vystoupit ze skupiny jejímž je èlenem.

Vstupní podmínky:
Uživatel je èlenem skupiny, z níž chce vystoupit && uživatel je pøihlášen

Scénáø:

	Uživatel vstoupí na stránku skupiny.

	Uživatel klikne na tlaèítko vystoupit ze skupiny

	Systém odebere uživatele ze seznamu èlenù skipiny.




Výstupní podmínky:
Uživatel je odebrán ze seznamu èlenù skupiny.


Notes:
Struèný popis:
Uživatel chce napsat zprávu jinému uživateli.

Vstupní podmínky:
Uživatel je pøihlášen.

Scénáø:

	Uživatel vstoupí na stránku pošta.

	Uživatel vybere možnost napsat zprávu.

	Systém zobrazí dialog pro odesílání zprávy.

	Uživatel dialog vyplní a odešle.

	Systém zkontroluje zda adresát existuje.

	IF neexistuje vypíše chybovou hlášku

	ELSE odešle zprávu.




Výstupní podmínky:
Adresátovi je odeslána zpráva.


Notes:
Struèný popis:
Uživatel pøidává pøíspìvky do diskuze skupiny. 

Vstupní podmínky:
uživatel je pøihlášený && uživatel je èlenem skupiny

Scénáø:

	Uživatel vstoupí ze stránky skupiny na stránku zeï diskuze skupiny.

	Uživatel klikne na tlaèítko reagovat / vytvoøit nový pøíspìvek

	Systém zobrazí formuláø pro pøidání pøíspìvku.

	Uživatel vyplní formuláø a potvrdí

	Systém pøidá pøíspìvek do diskuze




Výstupní podmínky:
Pøíspìvek je uložen v databázi.


Notes:
Struèný popis:
Uživatel chce zmìnit informace zobrazované na svém profilu.

Vstupní podmínky:
Uživatel je pøihlášený

Scénáø:

	Uživatel klikne na tlaèítko editovat profil.

	Systém zobrazí všechny informace v editovatelné podobì.

	Uživatel provede požadované zmìny.

	Uživatel stiskne tlaèítko pro uložení zmìn.

	Systém uloží zmìny do databáze.




Výstupní podmínky:
Zmìny profilu jsou uloženy v databázi.


Notes:
Struèný popis:
Zakladatel skupiny se rozhodne zmìnit in informace o skupinì zobrazované na její kartì.

Vstupní podmínky:
uživatel je pøihlášen

Scénáø:

	Uživatel vstoupí na kartu skupiny.

	Uživatel klikne na tlaèítko zmìnit informace o skupinì.

	Systém zobrazí  informace o skupinì v editovatelné podobì.

	Uživatel provede požadované zmìny.

	Uživatel klikne na tlaèítko uložit zmìny.

	Systém uloží provedené zmìny.




Výstupní podmínky:
Zmìny informací jsou uloženy v databázi.


Notes:
Struèný popis: 
Uživatel se rozhodne nastavit heslo pro vstup do skupiny. Bez znalosti hesla není možný vstup do skupiny.

Vstupní podmínky:
uživatel je pøihlášen 

Scénáø:

	Uživatel vstoupí na kartu skupiny.

	Uživatel klikne na tlaèítko zmìnit heslo.

	IF nìjaké heslo je již nastaveno ALTERNATIVNI scénáø

	Je zobrazeno okno do kterého uživatel dvakrát vypíše nové heslo

	Uživatel stiskne tlaèítko uložit nové heslo.

	Systém uloží nové heslo.




Výstupní podmínky:
Je nastaveno nové heslo pro vstup do skupiny.


Notes:
Struèný popis:
alternativní scénáø


Scénáø:

	Alternativni scénáø zaèíná bodem 2 hlavního scénáøe.

	Uživatel je vyzván k zadání stávajícího hesla

	Systém ovìøí správnost hesla.

	IF heslo souhlasí následuje bod 3 hlavního scénáøe.

	ELSE je zobrazena zpráva o nesprávnosti hesla

	UC konèí


Notes:
Struèný popis:
Uživatel chce zmìnit harmonogram skupiny.

Vstupní podmínky:
uživatel je pøihlášen

Scénáø:

	Uživatel vstoupí na kartu skupiny.

	Uživatel klikne na tlaèítko zmìnit harmonogram.

	Systém zobrazí harmonogram v editovatelné podobì.

	Uživatel provede požadované zmìny nebo pøidá další termíny.

	Uživatel stiskne tlaèítko uložit zmìny.

	Systém zmìny uloží.




Výstupní podmínky:
Provedené zmìny jsou uloženy v databázi.


Notes:
Struèný popis:
Uživatel chce zmìnit statávající aktualitu.

Vstupní podmínky:
Uživatel je pøihlášen

Scénáø:

	Uživatel vstoupí na kartu skupiny.

	Uživatel klikne na tlaèítko zmìnit stávající aktualitu.

	Systém zobrazí stávající aktualitu v editovatelní podobì.

	Uživatel provede požadovanou editaci a stiskne tlaèítko uložit zmìny,

	Systém uloží provedené zmìny.




Výstupní podmínky:
Zmìnìná aktualita je uložena v databázi.


Notes:
Struèný popis:
Uživatel chce vložit novou aktualitu ke skupinì.

Vstupní podmínky:
uživatel je pøihlášený 

Scénáø:

	Uživatel vstoupí na kartu skupiny.

	Uživatel klikne na tlaèítko pøidat aktualitu ke skupinì.

	Systém zobrazí formuláø pro pøidání aktuality.

	Uživatel vyplní formuláø (vepíše text aktuality) a stiskne tlaèítko uložit aktualitu.

	Systém uloží aktualitu ke skupinì.




Výstupní podmínky:
Nová aktualita je uložena v databázi.


Notes:
Struèný popis:
Uživatel se rozhodne zrušit jinému uživateli èlenství ve své skupinì.

Vstupní podmínky:
uživatel je pøihlášený 

Scénáø:

	Uživatel klikne na kartì skupiny na možnost odebrat èlenství.

	INCLUDE zobrazení èlenù skupiny

	Uživatel potvrdí odebrání èlenství kliknutím na možnost odebrat èlenství(zobrazena u každého uživatele skupiny)

	Systém zruší uživateli šlenství se skupinì.




Výstupní podmínky:
uživateli je zrušeno èlenství ve skupinì.


Notes:
Struèný popis:
Uživatel chce zobrazit všechny èleny skupiny.

Vstupní podmínky:
uživatel je pøihlášený && uživatel je èlenem skupiny

Scénáø:

	Uživatel vstoupí na stránku skupiny.

	Uživatel klikne na možnost zobraziz seznam èlenù skupiny.

	Systém zobrazí seznam èlenù skupiny.




Výstupní podmínky:
Je zobrazen seznam èlenù skupiny.


Notes:
Struèný popis:
Uživatel se rozhodne libovolnému uživateli zakázat vstup do skupiny.

Vstupní podmínky:
uživatel je pøihlášen

Scénáø:

	Uživatel vstoupí na kartu skupiny.

	Uživatel klikne na možnost zablokovat pøístup do skupiny

	zobrazí se formuláø na vyhledání uživatele

	INCLUDE vyhledání uživatele

	Uživatel po nalezení uživatele stiskne tlaèítko zablokovat pøístup.

	Systém zaøedí uživatele na seznam uživatelù, kteøí nemají povolen pøístup do skupiny.




Výstupní podmínky:
Zvolený uživatel je uložen mezi uživatele se zakázaným pøístupem do skupiny.


Notes:
Struèný popis:
Uživatel chce jmenovat správce skupiny.

Vstupní podmínky:
uživatel je pøihlášený

Scénáø:

	Uživatel vstoupí na kartu skupiny.

	Uživatel klikne na možnost jmenovat moderátora skupiny.

	INCLUDE zobrazení èlenù skupiny

	Uživatel vybere ze seznamu uživatele pro jmenování moderátorem a klikne na tlaèítko jmenovat moderátorem.

	Systém nastaví vybraného uživatele moderátorem skupiny




Výstupní podmínky:
Je jmenován moderátor skupiny.


Notes:
Struèný popis:
Uživatel chce odebrat moderátorovi jeho práva.

Vstupní podmínky:
uživatel je pøihlášený

Scénáø:

	Uživatel vstoupí na úvodní kartu skupiny.

	Uživatel klikne ma tlaèítko zrušit moderátora.

	Systém odebere moderátorovi moderátorství.




Výstupní podmínky:
Moderátorovi skupiny je odebrán status moderátora.


Notes:
Strucny popis:
Uživatel chce odebírat novinky o dìní ve skupinì.

Vstupni podminky:
uživatel je pøihlášený && je èlenem skupiny

Hlavni scenar:

	Uživatel vstoupí na stránku skupiny

	Uživatel stiskne tlaèítko pro odbìr novinek.

	Systém zaøadí uživatele mezi odbìretele novinek





Vystupni podminky:
Uživatel je zaøezen mezi odbìratele novinek.


Notes:
Strucny popis:
Uživatel chce pøestat odebírat novinky o skupinì.

Vstupni podminky:
uživatel je pøihlášený && sleduju deni ve skupine

Hlavni scenar:

	Uživatel vstoupí na stránku skupiny

	Uživatel stiskne tlaèítko pro zrušení odbìru novinek.

	Systém vyøadí uživatele ze seznamu odbìratelù novinek.




Vystupni podminky:
Uživatel je vyøazen ze seznamu odbìratelù novinek.


Notes:
Strucny popis:
Uživatel chce pøestat sledovat aktivitu jiného uživatele.

Vstupni podminky:
uživatel je pøihlášený && uzivatel je na seznamu mych sledovanych

Hlavni scenar:

	Uživatel vstoupí na profilovou stránku uživatele.

	Uživatel stiskne tlaèítko pro zrušení sledování uživatele.

	Systém vyøadí uživatele ze seznamu sledovaných uživatelù.




Vystupni podminky:
Uživatel je vyøazen ze seznamu sledovaných uživatelù.


# 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.


