Java is a programming language originally developed by James Gosling at Sun Microsystems (which has since merged into Oracle

Corporation) and released in 1995 as a core component of Sun Microsystems' Java platform. The language derives much of its syntax from C and C++, but it has fewer low-level facilities than either of them. Java applications are typically compiled to bytecode (class file) that can run on any Java virtual machine (JVM) regardless of computer architecture. Java is a general-purpose, concurrent, class-based, objectoriented language that is specifically designed to have as few implementation dependencies as possible. It is intended to let application developers "write once, run anywhere" (WORA), meaning that code that runs on one platform does not need to be recompiled to run on another. Java is as of 2012 one of the most popular programming languages in use, particularly for client-server web applications, with a reported 10 million users.[10][11] The original and reference implementation Java compilers, virtual machines, and class libraries were developed by Sun from 1991 and first released in 1995. As of May 2007, in compliance with the specifications of the Java Community Process, Sun relicensed most of its Java technologies under the GNU General Public License. Others have also developed alternative implementations of these Sun technologies, such as the GNU Compiler for Java and GNU Classpath. Duke, the Java mascotJames Gosling, Mike Sheridan, and Patrick Naughton initiated the Java language project in June 1991.[12] Java was originally designed for interactive television, but it was too advanced for the digital cable television industry at the time.[13] The language was initially called Oak after an oak tree that stood outside Gosling's office; it went by the name Green later, and was later renamed Java, from Java coffee, said to be consumed in large quantities by the language's creators.[14] Gosling aimed to implement a virtual machine and a language that had a familiar C/C++ style of notation.[15] Sun Microsystems released the first public implementation as Java 1.0 in 1995[1]. It promised "Write Once, Run Anywhere" (WORA), providing no-cost run-times on popular platforms. Fairly secure and featuring configurable security, it allowed network- and file-access restrictions. Major web browsers soon incorporated the ability to run Java applets within web pages, and Java quickly became popular. With the advent of Java 2 (released initially as J2SE 1.2 in December 19981999), new versions had multiple configurations built for different types of platforms. For example, J2EE targeted enterprise applications and the greatly stripped-down version J2ME for mobile applications (Mobile Java). J2SE designated the Standard Edition. In 2006, for marketing purposes, Sun renamed new J2 versions as Java EE, Java ME, and Java SE, respectively. In 1997, Sun Microsystems approached the ISO/IEC JTC1 standards body and later the Ecma International to formalize Java, but it soon withdrew from the process.[16] Java remains a de facto standard, controlled through the Java Community Process.[17] At one time, Sun made most of its Java implementations available without charge, despite their proprietary software status. Sun generated revenue from Java through the selling of licenses for specialized products such as the Java Enterprise System. Sun distinguishes between its Software Development Kit (SDK) and Runtime Environment (JRE) (a subset of the SDK); the primary distinction involves the JRE's lack of the compiler, utility programs, and header files. On November 13, 2006, Sun released much of Java as free and open source software, (FOSS), under the terms of the GNU General Public License (GPL). On May 8, 2007, Sun finished the process, making all of Java's core code available under free software/open-source distribution terms, aside from a small portion of code to which Sun did not hold the copyright.[18]

Sun's vice-president Rich Green said that Sun's ideal role with regards to Java was as an "evangelist."[19] Following Oracle Corporation's acquisition of Sun Microsystems in 2009 2010, Oracle has described itself as the "steward of Java technology with a relentless commitment to fostering a community of participation and transparency".[20] This did not hold Oracle, however, from filing a lawsuit against Google shortly after that for using Java inside the Android SDK (see Google section below). Java software runs on laptops to data centers,

game consoles to scientific supercomputers. There are 930 million Java Runtime Environment downloads each year and 3 billion mobile phones run Java.[21] On April 2, 2010, James Gosling resigned from Oracle.[22] Principles James Gosling, the creator of JavaThere were five primary goals in the creation of the Java language:[23] 1.It should be "simple, object-oriented and familiar" 2.It should be "robust and secure" 3.It should be "architecture-neutral and portable" 4.It should execute with "high performance" 5.It should be "interpreted, threaded, and dynamic" PracticesJava platformMain articles: Java (software platform) and Java virtual machine One characteristic of Java is portability, which means that computer programs written in the Java language must run similarly on any hardware/operating-system platform. This is achieved by compiling the Java language code to an intermediate representation called Java bytecode, instead of directly to platform-specific machine code. Java bytecode instructions are analogous to machine code, but they are intended to be interpreted by a virtual machine (VM) written specifically for the host hardware. End-users commonly use a Java Runtime Environment (JRE) installed on their own machine for standalone Java applications, or in a Web browser for Java applets. Standardized libraries provide a generic way to access host-specific features such as graphics, threading, and networking. A major benefit of using bytecode is porting. However, the overhead of interpretation means that interpreted programs almost always run more slowly than programs compiled to native executables would. Just-in-Time (JIT) compilers were introduced from an early stage that compile bytecodes to machine code during runtime. ImplementationsSee also: Free Java implementations Oracle Corporation is the current owner of the official implementation of the Java SE platform, following their acquisition of Sun Microsystems on January 27, 2010. This implementation is based on the original implementation of Java by Sun. The Oracle implementation is available for Mac OS X, Windows and Solaris. Because Java lacks any formal standardization recognized by Ecma International, ISO/IEC, ANSI, or other thirdparty standards organization, the Oracle implementation is the de facto standard. The Oracle implementation is packaged into two different distributions: The Java Runtime Environment (JRE) which contains the parts of the Java SE platform required to run Java programs and is intended for end-users, and the Java Development Kit (JDK), which is intended for software developers and includes development tools such as the Java compiler, Javadoc, Jar, and a debugger. OpenJDK is another notable Java SE implementation that is licensed under the GPL. The implementation started when Sun began releasing the Java source code under the GPL. As of Java SE 7, OpenJDK is the official Java reference implementation. The goal of Java is to make all implementations of Java compatible. Historically, Sun's trademark license for usage of the Java brand insists that all implementations be "compatible." This resulted in a legal dispute with Microsoft after Sun claimed that the Microsoft implementation did not support RMI or JNI and had added platform-specific features of their own. Sun sued in 1997, and in 2001 won a settlement of US$20 million, as

well as a court order enforcing the terms of the license from Sun.[24] As a result, Microsoft no longer ships Windows with Java. Platform-independent Java is essential to Java EE, and an even more rigorous validation is required to certify an implementation. This environment enables portable server-side applications. Programs written in Java have a reputation for being slower and requiring more memory than those written in C.[25][26] However, Java programs' execution speed improved significantly with the introduction of Just-intime compilation in 1997/1998 for Java 1.1,[27] the addition of language features supporting better code analysis (such as inner classes, the StringBuffer class, optional assertions, etc.), and optimizations in the Java virtual machine itself, such as HotSpot becoming the default for Sun's JVM in 2000. As of February 2012, microbenchmarks show Java 7 is approximately 1.5 times slower than C.[28] Some platforms offer direct hardware support for Java; there are microcontrollers that can run Java in hardware instead of a software Java virtual machine, and ARM based processors can have hardware support for executing Java bytecode through their Jazelle option. Automatic memory managementJava uses an automatic garbage collector to manage memory in the object lifecycle. The programmer determines when objects are created, and the Java runtime is responsible for recovering the memory once objects are no longer in use. Once no references to an object remain, the unreachable memory becomes eligible to be freed automatically by the garbage collector. Something similar to a memory leak may still occur if a programmer's code holds a reference to an object that is no longer needed, typically when objects that are no longer needed are stored in containers that are still in use. If methods for a nonexistent object are called, a "null pointer exception" is thrown.[29][30] One of the ideas behind Java's automatic memory management model is that programmers can be spared the burden of having to perform manual memory management. In some languages, memory for the creation of objects is implicitly allocated on the stack, or explicitly allocated and deallocated from the heap. In the latter case the responsibility of managing memory resides with the programmer. If the program does not deallocate an object, a memory leak occurs. If the program attempts to access or deallocate memory that has already been deallocated, the result is undefined and difficult to predict, and the program is likely to become unstable and/or crash. This can be partially remedied by the use of smart pointers, but these add overhead and complexity. Note that garbage collection does not prevent "logical" memory leaks, i.e. those where the memory is still referenced but never used. Garbage collection may happen at any time. Ideally, it will occur when a program is idle. It is guaranteed to be triggered if there is insufficient free memory on the heap to allocate a new object; this can cause a program to stall momentarily. Explicit memory management is not possible in Java. Java does not support C/C++ style pointer arithmetic, where object addresses and unsigned integers (usually long integers) can be used interchangeably. This allows the garbage collector to relocate referenced objects and ensures type safety and security. As in C++ and some other object-oriented languages, variables of Java's primitive data types are not objects. Values of primitive types are either stored directly in fields (for objects) or on the stack (for methods) rather than on the heap, as commonly true for objects (but see Escape analysis). This was a conscious decision by Java's designers for performance reasons. Because of this, Java was not considered to be a pure objectoriented programming language. However, as of Java 5.0, autoboxing enables programmers to proceed as if primitive types were instances of their wrapper class. Java contains multiple types of garbage collectors. By default, HotSpot uses the Concurrent Mark Sweep collector, also known as the CMS Garbage Collector. However, there are also several other garbage collectors

that can be used to manage the Heap. For 90% of applications in Java, the CMS Garbage Collector is good enough.[31] SyntaxMain article: Java syntax The syntax of Java is largely derived from C++. Unlike C++, which combines the syntax for structured, generic, and object-oriented programming, Java was built almost exclusively as an object-oriented language. All code is written inside a class, and everything is an object, with the exception of the primitive data types (e.g. integers, floating-point numbers, boolean values, and characters), which are not classes for performance reasons. Unlike C++, Java does not support operator overloading or multiple inheritance for classes. This simplifies the language and aids in preventing potential errors and anti-pattern design. Java uses similar commenting methods to C++. There are three different styles of comments: a single line style marked with two slashes (//), a multiple line style opened with /* and closed with */, and the Javadoc commenting style opened with /** and closed with */. The Javadoc style of commenting allows the user to run the Javadoc executable to compile documentation for the program. Example:

// This is an example of a single line comment using two slashes

/* This is an example of a multiple line comment using the slash and asterisk. This type of comment can be used to hold a lot of information or deactivate code, but it is very important to remember to close the comment. */

/** * This is an example of a Javadoc comment; Javadoc can compile documentation * from this text. */

Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group. It was first added to the list of OMG adopted technologies in 1997, and has since become the industry standard for modeling software-intensive systems.[1] UML includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems. UML is used to specify, visualize, modify, construct and document the artifacts of an object-oriented softwareintensive system under development.[2] UML offers a standard way to visualize a system's architectural blueprints, including elements such as: activities actors business processes database schemas (logical) components programming language statements reusable software components.[3]

UML combines techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies.[4] UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language. [citation needed] UML aims to be a standard modeling language which can model concurrent and distributed systems. UML is a de facto industry standard[citation needed]. UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages. UML is extensible, with two mechanisms for customization: profiles and stereotypes. Topics [edit] Software development methods UML is not a development method by itself;[11] however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT, Booch method, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notations (for example OMT), and new methods have been created based on UML, such as IBM Rational Unified Process (RUP). Others include Abstraction Method and Dynamic Systems Development Method. [edit] Modeling It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphic representation of a system's model. The model also contains documentation that drives the model elements and diagrams (such as written use cases). UML diagrams represent two different views of a system model: [12] Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams. Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.

UML models can be exchanged among UML tools by using the XMI interchange format.

Structure diagrams Structure diagrams emphasize the things that must be present in the system being modeled. Since structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems. Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes. Component diagram: describes how a software system is split up into components and shows the dependencies among these components. Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible. Deployment diagram: describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware. Object diagram: shows a complete or partial view of the structure of an example modeled system at a specific time. Package diagram: describes how a system is split up into logical groupings by showing the dependencies among these groupings. Profile diagram: operates at the metamodel level to show stereotypes as classes with the <<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype. The extension relation (solid line with closed, filled arrowhead) indicates what metamodel element a given stereotype is extending

A use case diagram at its simplest is a graphical representation of a user's interaction with the system and depicting the specifications of a use case. A use case diagram can portray the different types of users of a system and the various ways that they interact with the system. This type of diagram is typically used in conjunction with the textual use case and will often be accompanied by other types of diagrams as well. Construction Actors are portrayed in a use case diagram as a stick figure and represent external factors that will provide interaction with the system. The term "actors" are frequently interchanged with the term "users"; however an actor does not necessarily have to be a human user. An actor could be other systems or some other form of external input into the system. [1] The system delimitation visually defines what components will be part of the system and what factors are external. Actors are portrayed outside of the rectangular box that represents the system boundary. Within that box contains the different functions, or use cases, of the system. The boundary provides a means of segregating internal and external factors and also provides a means of showing the interaction between the two types of factors.[2] Use cases are all of the functionality of the system that is contained within the system boundary. The actors will interact in some means with the individual use case and each use case will represent a concise portion of functionality.[3] The individual use cases will be represented by ovals within the rectangular system boundary. Actors will interact with the use case by means of arrows. Association refers to how individual use cases can be linked together based upon certain functionality. These are drawn as lines or arrows from the originating item to the appropriate use case. o Extension is an association between two use cases where the functionality of some use cases is similar but could have some deviations or additions depending on the scenario. [4] For example: when purchasing concert tickets, there is a standard use case for telephone sales, but some variations could come into play if the performance is completely full. o Inclusion is an association between use cases where there is a chunk of functionality that is inclusive in multiple cases and can be abstracted into a separate model and essentially "included" in other use cases.[5] For example: when filling up your car with gasoline, some options include paying at the pump with a credit card or paying inside the convenience store with a credit card (among other options). The use case of "Process credit card payment" would be functionality that could be included in either scenario. o Generalization is an association between use cases where the basic functionality is the same, but specific implementation details may differ.[6] For example: the use case of "Purchase a shirt" is a general way to describe a customer making a purchase from a retailer. This purchase could be made in different ways depending on if the user purchases online versus the actual store. While either scenario would have some common "general" characteristics, there will still be some differences as well.

Application It is a very well known adage that "A picture is worth a thousand words". With regards to use case diagrams, that is exactly what they are meant to do. While a use case itself might drill into a lot of detail about every possibility, a use case diagram can help provide a higher-level view of the system. It has been said before that "Use case diagrams are the blueprints for your system".[7] They provide the simplified and graphical representation of what the system must actually do. Due to their simplistic nature, use case diagrams can be a good communication tool for stakeholders. The drawings attempt to mimic the real world and provide a view for the stakeholder to understand how the system is going to be designed. Siau and Lee conducted research to determine if there was a valid situation for use case diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent of the system in a more simplified manner to stakeholders and that they were "interpreted more completely than class diagrams".[8] The purpose of the use case diagrams is simply to provide the high level view of the system and convey the requirements in layman's terms for the stakeholders. Additional diagrams and documentation can be used to provide a complete functional and technical view of the system. [edit] Limitations As stated above, a use case diagram is not a standalone model, but one that can be used in conjunction with other models as well. Since the main purpose is to outline general behavior, the use case diagram should "focus on

business goals rather than system goals".[9] A use case diagram is not meant to technically outline the functionality of the system, but to provide the business reasoning and outcomes of the system. [edit] Tips Always structure and organize the use case diagram from the perspective of the actor.[10] Use cases should start off simple and at the highest view possible. Only then can they be refined and detailed further.[11] Use case diagrams are based upon functionality and thus should focus on the "what" and not the "how".[12]

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among the classes. Overview

Hierarchy of UML 2.0 Diagrams, shown as a class diagram. The individual classes are represented just with one compartment, but they often contain up to three compartments. The class diagram is the main building block of object oriented modelling. It is used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code. Class diagrams can also be used for data modeling.[1] The classes in a class diagram represent both the main objects, interactions in the application and the classes to be programmed.

A class with three sections. In the diagram, classes are represented with boxes which contain three parts: [2] The upper part holds the name of the class The middle part contains the attributes of the class The bottom part gives the methods or operations the class can take or undertake

In the design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the static relations between those objects. With detailed modeling, the classes of the conceptual design are often split into a number of subclasses. In order to further describe the behavior of systems, these class diagrams can be complemented by state diagram or UML state machine. Also instead of class diagrams Object role modeling can be used if you just want to model the classes and their relationships.[2] [edit] Members UML provides mechanisms to represent class members, such as attributes and methods, and additional information about them. [edit] Visibility To specify the visibility of a class member (i.e., any attribute or method) these are the following notations that must be placed before the member's name [3]: All the Visibility of a Class Members Are: + Public

# ~ / underline [edit] Scope

Private Protected Package Derived Static

The UML specifies two types of scope for members: instance and classifier. [4] Classifier members are commonly recognized as "static" in many programming languages. In the case of instance members, the scope is a specific instance. For attributes, it means that its value can vary between instances. For methods, it means that its invocation affects the instance state, in other words, affects the instance attributes. Otherwise, in the classifier member, the scope is the class. For attributes, it means that its value is equal for all instances. For methods, it means that its invocation does not affect the instance state. To indicate that a member has the classifier scope, its name must be underlined. Otherwise, as default, the instance scope is considered. [edit] Relationships A relationship is a general term covering the specific types of logical connections found on class and object diagrams. UML shows the following relationships: [edit] Instance level relationships [edit] External links A Link is the basic relationship among objects. [edit] Association

Class diagram example of association between two classes An association represents a family of links. Binary associations (with two ends) are normally represented as a line. An association can be named, and the ends of an association can be adorned with role names, ownership indicators, multiplicity, visibility, and other properties. There are four different types of association: bi-directional, uni-directional, Aggregation (includes Composition aggregation) and Reflexive. Bi-directional and uni-directional associations are the most common ones. For instance, a flight class is associated with a plane class bi-directionally. Association represents the static relationship shared among the objects of two classes. Example: "department offers courses", is an association relation. [edit] Aggregation

Class diagram showing Aggregation between two classes Aggregation is a variant of the "has a" or association relationship; aggregation is more specific than association. It is an association that represents a part-whole or part-of relationship. As a type of association, an aggregation can be named and have the same adornments that an association can. However, an aggregation may not involve more than two classes.

Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the containeressentially, if the container is destroyed, its contents are not. In UML, it is graphically represented as a hollow diamond shape on the containing class end of the tree with a single line that connects the contained class to the containing class. [edit] Composition

Class diagram showing Composition between two classes at top and Aggregation between two classes at bottom Composition is a stronger variant of the "owns a" or association relationship; composition is more specific than aggregation. Composition usually has a strong life cycle dependency between instances of the container class and instances of the contained class(es): If the container is destroyed, normally every instance that it contains is destroyed as well. (Note that, where allowed, a part can be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite.) With composition (aggregation), an arrow points to the contained class[inconsistent], and the black diamond points towards the container class. The UML graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class. [edit] Differences between composition and aggregation When attempting to represent real-world whole-part relationships, e.g., an engine is a part of a car, the composition relationship is most appropriate. However, when representing a software or database relationship, e.g., car model engine ENG01 is part of a car model CM01, an aggregation relationship is best, as the engine, ENG01 may be also part of a different car model. Thus the aggregation relationship is often called "catalog" containment to distinguish it from composition's "physical" containment. The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must belong to only one whole; the part may have any multiplicity. For example, consider University and Department classes. A department belongs to only one university, so University has multiplicity 1 in the relationship. A university can (and will likely) have multiple departments, so Department has multiplicity 1..*. [edit] Class level relationships [edit] Generalization

Class diagram showing generalization between one superclass and two subclasses

The Generalization relationship ("is a") indicates that one of the two related classes (the subclass) is considered to be a specialized form of the other (the super type) and superclass is considered as 'Generalization' of subclass. In practice, this means that any instance of the subtype is also an instance of the superclass. An exemplary tree of generalizations of this form is found in binomial nomenclature: human beings are a subclass of simian, which are a subclass of mammal, and so on. The relationship is most easily understood by the phrase 'an A is a B' (a human is a mammal, a mammal is an animal). The UML graphical representation of a Generalization is a hollow triangle shape on the superclass end of the line (or tree of lines) that connects it to one or more subtypes. The generalization relationship is also known as the inheritance or "is a" relationship. The superclass(base class) in the generalization relationship is also known as the "parent", superclass, base class, or base type. The subtype in the specialization relationship is also known as the "child", subclass, derived class, derived type, inheriting class, or inheriting type. Note that this relationship bears no resemblance to the biological parent/child relationship: the use of these terms is extremely common, but can be misleading. Generalization-Specialization relationship A is a type of B E. g. "an oak is a type of tree", "an automobile is a type of vehicle" Generalization can only be shown on class diagrams and on Use case diagrams. [edit] Realization In UML modeling, a realization relationship is a relationship between two model elements, in which one model element (the client) realizes (implements or executes) the behavior that the other model element (the supplier) specifies. The UML graphical representation of a Realization is a hollow triangle shape on the interface end of the dashed line (or tree of lines) that connects it to one or more implementors. A plain arrow head is used on the interface end of the dashed line that connects it to its users. In component diagrams, the ball-and-socket graphic convention is used (implementors expose a ball or lollipop, while users show a socket). Realizations can only be shown on class or component diagrams. A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element. A realization relationship between classes and interfaces and between components and interfaces shows that the class realizes the operations offered by the interface. [edit] General relationship

Class diagram showing dependency between "Car" class and "Wheel" class (An even clearer example would be "Car depends on Fuel", because Car already aggregates (and not just uses) Wheel)

[edit] Dependency Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time. One class depends on another if the independent class is a parameter variable or local variable of a method of the dependent class. This is different from an association, where an attribute of the dependent class is an instance of the independent class. [edit] Multiplicity The association relationship indicates that (at least) one of the two related classes makes reference to the other. In contrast with the generalization relationship, this is most easily understood through the phrase 'A has a B' (a mother cat has kittens, kittens have a mother cat). The UML representation of an association is a line with an optional arrowhead indicating the role of the object(s) in the relationship, and an optional notation at each end indicating the multiplicity of instances of that entity (the number of objects that participate in the association). 0..1 No instances, or one instance (optional, may) Exactly one instance 1 0..* or * Zero or more instances 1..* One or more instances (at least one) [edit] Analysis stereotypes In the early stages of a project's technical analysis, class diagrams can be used to produce early conceptual models of the system. Classes at this stage often take the form of boundaries, controls and entities and rarely survive into the design without heavy changes.

[edit] Boundaries Boundary classes handle the communication between actors and the system's internal components. They might be user interfaces, system interfaces or device interfaces (for example). They are identified by each actor usecase pair on the system's use-case diagram, with one and only one boundary class existing for each pair [why?][citation needed] . They are drawn as circles with a short line to the left attached to a vertical line the same height as the circle (as though it is attached to the side of the use-case system boundary). Alternatively, they can be drawn as normal classes with the boundary stereotype notation above the class name. [edit] Entities Entity classes model the information handled by the system, and sometimes the behaviour associated with the information. They should not be identified as database tables or other data-stores

They are drawn as circles with a short line attached to the bottom of the circle. Alternatively, they can be drawn as normal classes with the entity stereotype notation above the class name [edit] Controls Control classes handle the flow of control for a use-case and can therefore be seen as co-ordinating representation classes. These do not do everything in the use case, but co-ordinate with other classes that can do the work for them.

The American Standard Code for Information Interchange (ASCII, pronunciation: /ski/ ASS-kee;[3]) is a character-encoding scheme originally based on the English alphabet. ASCII codes represent text in computers, communications equipment, and other devices that use text. Most modern character-encoding schemes are based on ASCII, though they support many additional characters. ASCII developed from telegraphic codes. Its first commercial use was as a seven-bit teleprinter code promoted by Bell data services. Work on the ASCII standard began on October 6, 1960, with the first meeting of the American Standards Association's (ASA) X3.2 subcommittee. The first edition of the standard was published during 1963,[4][5] a major revision during 1967,[6] and the most recent update during 1986.[7] Compared to earlier telegraph codes, the proposed Bell code and ASCII were both ordered for more convenient sorting (i.e., alphabetization) of lists and added features for devices other than teleprinters. ASCII includes definitions for 128 characters: 33 are non-printing control characters (many now obsolete)[8] that affect how text and space is processed[9] and 95 printable characters, including the space (which is considered an invisible graphic[1][2]). The IANA prefers the name US-ASCII[10] to avoid ambiguity. ASCII was the most commonly used character encoding on the World Wide Web until December 2007, when it was surpassed by UTF-8.[11][12][13] Unicode is a computing industry standard for the consistent encoding, representation and handling of text expressed in most of the world's writing systems. Developed in conjunction with the Universal Character Set standard and published in book form as The Unicode Standard, the latest version of Unicode consists of a repertoire of more than 110,000 characters covering 100 scripts, a set of code charts for visual reference, an encoding methodology and set of standard character encodings, an enumeration of character properties such as upper and lower case, a set of reference data computer files, and a number of related items, such as character properties, rules for normalization, decomposition, collation, rendering, and bidirectional display order (for the correct display of text containing both rightto-left scripts, such as Arabic and Hebrew, and left-to-right scripts).[1] As of September 2012, the most recent version is Unicode 6.2. Unicode's success at unifying character sets has led to its widespread and predominant use in the internationalization and localization of computer software. The standard has been implemented in many recent technologies, including XML, the Java programming language, the Microsoft .NET Framework, and modern operating systems. Unicode can be implemented by different character encodings. The most commonly used encodings are UTF-8, UTF-16 and the now-obsolete UCS-2. UTF-8 uses one byte for any ASCII characters, which have the same code values in both UTF-8 and ASCII encoding, and up to four bytes for other characters. UCS-2 uses a 16-bit code unit (two 8-bit bytes) for each character but cannot encode every character in the current Unicode standard. UTF-16 extends UCS-2, using two 16-bit units (4 8 bit) to handle each of the additional characters. In IBM PC compatible computers, the Basic Input/Output System (BIOS), also known as the system BIOS or ROM BIOS ( /ba.os/), is a de facto standard defining a firmware interface.[1] The name originated from the Basic Input Output System used in the CP/M operating system (released in 1976), where the BIOS was loaded from disk, with only a small boot loader program stored in read-only memory.

The BIOS software is built into the PC, and is the first code run by a PC when powered on ('boot firmware'). When the PC starts up, the first job for the BIOS is the power-on self-test, which initializes and identifies system devices such as the CPU, RAM, video display card, keyboard and mouse, hard disk drive, optical disc drive and other hardware. The BIOS then locates boot loader software held on a peripheral device (designated as a 'boot device'), such as a hard disk or a CD/DVD, and loads and executes that software, giving it control of the PC.[2] This process is known as booting, or booting up, which is short for bootstrapping. BIOS software is stored on a non-volatile ROM chip on the motherboard. It is specifically designed to work with each particular model of computer, interfacing with various devices that make up the complementary chipset of the system. In modern computer systems, the BIOS chip's contents can be rewritten without removing it from the motherboard, allowing BIOS software to be upgraded in place. A BIOS has a user interface (UI), typically a menu system accessed by pressing a certain key on the keyboard when the PC starts. In the BIOS UI, a user can:

configure hardware set the system clock enable or disable system components select which devices are eligible to be a potential boot device set various password prompts, such as a password for securing access to the BIOS user interface functions itself and preventing malicious users from booting the system from unauthorized peripheral devices.

The BIOS provides a small library of basic input/output functions used to operate and control the peripherals (such as the keyboard, text display functions and so forth), and these software library functions are callable by external software. In the IBM PC and AT, certain peripheral cards, such as hard-drive controllers and video display adapters, carried their own BIOS extension Option ROM, which provided additional functionality. Operating systems and executive software, designed to supersede this basic firmware functionality, provide replacement software interfaces to applications. The role of the BIOS has changed over time. As of 2011, the BIOS is being replaced by the more complex Extensible Firmware Interface (EFI) in many new machines, but BIOS remains in widespread use. EFI booting has been supported in only Microsoft Windows versions supporting GPT,[3] the Linux kernel 2.6.1 and later, and Mac OS X on Intel-based Macs.[4] However, the distinction between BIOS and EFI is rarely made in terminology by the average computer user, making BIOS a catch-all term for both systems. Ethernet /irnt/ is a family of computer networking technologies for local area networks (LANs). Ethernet was commercially introduced in 1980 and standardized in 1985 as IEEE 802.3. Ethernet has largely replaced competing wired LAN technologies. The Ethernet standards comprise several wiring and signaling variants of the OSI physical layer in use with Ethernet. The original 10BASE5 Ethernet used coaxial cable as a shared medium. Later the coaxial cables were replaced by twisted pair and fiber optic links in conjunction with hubs or switches. Data rates were periodically increased from the original 10 megabits per second, to 100 gigabits per second.

Systems communicating over Ethernet divide a stream of data into shorter pieces called frames. Each frame contains source and destination addresses and error-checking data so that damaged data can be detected and re-transmitted. As per the OSI model Ethernet provides services up to and including the data link layer. Since its commercial release, Ethernet has retained a good degree of compatibility. Features such as the 48-bit MAC address and Ethernet frame format have influenced other networking protocols. Total cost of ownership (TCO) is a financial estimate whose purpose is to help consumers and enterprise managers determine direct and indirect costs of a product or system. It is a management accounting concept that can be used in full cost accounting or even ecological economics where it includes social costs. For manufacturing, as TCO is typically compared with doing business overseas, it goes beyond the initial manufacturing cycle time and cost to make parts. TCO includes a variety of cost of doing business items, for example, ship and reship, opportunity costs, while it also considers incentives developed for an alternative approach. Incentives and other variables include tax credits, common language, expediated delivery, customer oriented supplier visits. TCO, when incorporated in any financial benefit analysis, provides a cost basis for determining the total economic value of an investment. Examples include: return on investment, internal rate of return, economic value added, return on information technology, and rapid economic justification. A TCO analysis includes total cost of acquisition and operating costs. A TCO analysis is used to gauge the viability of any capital investment. An enterprise may use it as a product/process comparison tool. It is also used by credit markets and financing agencies. TCO directly relates to an enterprise's asset and/or related systems total costs across all projects and processes, thus giving a picture of the profitability over time.

[edit] Computer and software industries

TCO analysis was popularized by the Gartner Group in 1987.[1] The roots of this concept date at least back to the first quarter of the twentieth century.[2] Many different methodologies and software tools have been developed to analyze TCO. TCO tries to quantify the financial impact of deploying an information technology product over its life cycle. These technologies include software and hardware, and training. Technology deployment can include the following as part of TCO:

Computer hardware and programs o Network hardware and software o Server hardware and software o Workstation hardware and software o Installation and integration of hardware and software o Purchasing research o Warranties and licenses o License tracking - compliance o Migration expenses o Risks: susceptibility to vulnerabilities, availability of upgrades, patches and future licensing policies, etc.

Operation expenses o Infrastructure (floor space) o Electricity (for related equipment, cooling, backup power) o Testing costs o Downtime, outage and failure expenses o Diminished performance (i.e. users having to wait, diminished money-making ability) o Security (including breaches, loss of reputation, recovery and prevention) o Backup and recovery process o Technology training o Audit (internal and external) o Insurance o Information technology personnel o Corporate management time Long term expenses o Replacement o Future upgrade or scalability expenses o Decommissioning

In the case of comparing TCO of existing versus proposed solutions, consideration should put towards costs required to maintain the existing solution that may not necessarily be required for a proposed solution. Examples include cost of manual processing that are only required to support lack of existing automation, and extended support personnel.

Transportation industry
The TCO concept is widely used in the transportation industry. For example, the TCO defines the cost of owning an automobile from the time of purchase by the owner, through its operation and maintenance to the time it leaves the possession of the owner. Comparative TCO studies between various models help consumers choose a car to fit their needs and budget. Some of the key elements incorporated in the cost of ownership for a vehicle include[3]:

Depreciation costs Fuel costs Insurance Financing Repairs Fees and taxes Maintenance costs Opportunity costs Downtime costs