Basic Concept of UML

the physical devices that the system will be executed on and consider whether writer need to coordinate shared resources.

4 Component Design

The starting point for component design is the architectural specification and the system requirements. The result of this activity is specification of the connected components. The component design builds on two general principles. The first is respect the component architecture; the second is adapting component designs to the technical possibilities. 2.7 Object-Oriented Design and Modeling Using the UML Unified Modeling Language

2.7.1 Basic Concept of UML

Based on Munawar 2005, UML is a language with a very broad scope that covers a large and diverse set of application domains. Not all of its modeling capabilities are necessarily useful in all domains or applications. This suggests that the language should be structured modularly, with the ability to select only those parts of the language that are of direct interest. On the other hand, an excess of this type of flexibility increases the likelihood that two different UML tools will be supporting different subsets of the language, leading to interchange problems between them. Consequently, the definition of compliance for UML requires a balance to be drawn between modularity and ease of interchange.UML is the work of a consortium of various organizations that successfully used as a standard in OOAD. Contributions to the UML have been generated from many reputable companies. As a programming language, UML can translate the diagram into the code that is ready to run.[19] Five types of diagrams used in this thesis are: 1 Use Cases Diagram Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The subject is the system under consideration to which the use cases apply. The users and any other systems that may interact with the subject are represented as actors. Actors always model entities that are outside the system. The required behavior of the subject is specified by one or more use cases, which are defined according to the needs of actors. Strictly speaking, the term “use case” refers to a use case type. An instance of a use case refers to an occurrence of the emergent behavior that conforms to the corresponding use case type. Such instances are often described by interaction specifications. 2 Statechart Diagram State machines can be used to specify behavior of various model elements. For example, they can be used to model the behavior of individual entities e.g., class instances. The state machine formalism described in this sub clause is an object-based variant of Harel statecharts. 3 Activity Diagram The focus of activity modeling is the sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors. These are commonly called control flow and object flow models. The behaviors coordinated by these models can be initiated because other behaviors finish executing, because objects and data become available, or because events occur external to the flow. 4 Class Diagram The Classes package contains sub packages that deal with the basic modeling concepts of UML, and in particular classes and their relationships. 5 Sequence Diagram The most common kind of Interaction Diagram is the Sequence Diagram, which focuses on the Message interchange between a numbers of Lifelines. A sequence diagram describes an Interaction by focusing on the sequence of Messages that are exchanged, along with their corresponding Occurrence Specifications on the Lifelines. The Interactions that are described by Sequence Diagrams are described in this clause. 6 Deployment Diagram Deployment diagrams show the allocation of Artifacts to Nodes according to the Deployments defined between them. 2.8. Various Platform 2.8.1. Blackberry