Available CategoriesAdobeMacromediaProgrammingSQLServer AdministrationNetworkingMicrosoft ProductsMac OSLinux systemsMobile devicesXMLCertificationMiscAvailable Tutorials.NET Framework Essentials.NET Programming securityC# In A Nutshell TutorialProgramming C.SharpMastering Visual Studio .NETASP.NETWeb Solutions based on ASP.NET and ADO.NETJava data objectsJava extreme programmingJava performance tuningJava development on pda's. Building applications for pocket pc and palm devicesJavaScript and DHTMLLearning UMLUMLLearning XMLCocoaProgramming CppPerl objects, references and modulesPerl tutorialPython tutorialPython. Text processingPocket pc network programmingPHP & MySQL. Building web database applicationsPHP & MySQL. Programming for beginnersPHP, MySQL and Apache in 24 hoursSoftware architecture in practiceSoftware engineering and computer gamesBuilding Solutions With the Microsoft .NET Compact FrameworkProgramming Microsoft Visual C# 2005ActionscriptMastering Delphi 7Ado.netPractical mod_perlPerl for bioinformaticsWeb ServicesPrinciples of Secure CodingC/C++ Secure ProgrammingASP.NET AJAXVisual C#Borland C++ Builder 6 Developer's Guide |
FrozenFrozenFrozen is a constraint that the UML defines as applicable to an attribute or an association end, but I find it useful for classes as well. On an attribute or association end, frozen indicates that the value of that attribute or association end may not change during the lifetime of the source object. The value must be set at object creation and may never change after that. The initial value may be null. Of course, if that's true when the object is constructed, it will be true as long as the object is alive. This implies that there is usually an argument for this value in a constructor and that there is no operation that updates this value. When applied to a class, frozen indicates that all association ends and attributes associated with that class are frozen. Frozen is not the same as read-only. Read-only implies that a value cannot be changed directly but may change due to a change in some other value. For instance, if a person has a date of birth and an age, the age may be read-only, but it cannot be frozen. I mark "freezing" using the {frozen} constraint, and I mark read-only values with {read only}. (Note that Read Only is not a standard UML property.) If you are thinking of "freezing" something, bear in mind that people make mistakes. In software, we model what we know about the world, not how the world is. If we were modeling how the world is, a "date of birth" attribute for a Person object would be frozen, but for most cases, we would want to change it if we found that a previous recording was incorrect. |