VIIT, Pune

Lab Manual

VIIT, Pune

LAB MANUAL Object Oriented Modeling and Design For 2011-2012

ISSUE NO. : 01 ISSUE DATE : 07/07/11 COPY NO. : 01 COPYHOLDER : PRACTICAL IC

BANSILAL RAMNATH AGARWAL CHARITABLE TRUSTS

VISHWAKARMA INSTITUTE OF INFORMATION TECHNOLOGY Sr. No 2/3/4 , Kondhwa ( Bk) , Pune -48

DEPARTMENT OF COMPUTER ENGINEERING

LAB MANUAL
FOR Object Oriented Modeling and Design(2008 Course) B.E.COMPUTER Subject Code: 410443

Teaching Scheme: 4 Hrs/Week Practical: 2Hrs/ Week

Examination Scheme: Term Work: 25 Marks Oral: 50 Marks

INDEX

Sr. No. 1 2 3 4

Assignments

Page No

5 6 7

For a hypothetical system write an SRS.(Consider BE Project) Draw one or more Use Case diagrams for a chosen system. Draw activity diagrams for a chosen system. A) Draw basic class diagrams for chosen system. B) Draw advanced class diagrams to depict advanced relationships, other classifiers like interfaces. Draw sequence diagrams or communication diagram with advanced notation for a chosen system. exchanges. Draw state machines to model the behavior of a single object. (Consider any Embedded/Real Time Systems) Draw component diagrams for a chosen system where some existing components will be reused while development.(Consider Web based System) Draw deployment diagrams for modeling the runtime architecture of a chosen system.(Consider Web based/Network/Embedded System)

7 11 17 25

35 40 48

52

Reviewed By: Subject Incharge

Approved By: HOD

Objectives of lab:
1. To learn how to understand the requirements of system, its scopes. 2. To learn good design, good modeling practices, document than and be able to discuss pros and cons of your designs and models. 3. To learn issues in modeling large, complex systems with example hypothetical systems. 4. To learn concepts, best practices in software, firmware development today and advanced concepts and notations for the same. 5. To use UML diagrams for modeling different aspects of the system throughout SDLC life Cycle 6. To model an entire system using UML. 7. To learn effective use of any case tool for UML.

Object Oriented Modeling and Design

History of UML:
Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980s as various methodologists experimented with different approaches to object-oriented analysis and design. The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994. Many users of OO methods had trouble finding complete satisfaction in any one modeling language, fueling the "method wars." By the mid-1990s, new iterations of these methods began to appear and these methods began to incorporate each others techniques, and a few clearly prominent methods emerged.1 The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (ObjectOriented Software Engineering) method.1 As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. First, these methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying the semantics and notation, they could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. Third, they expected that their collaboration would yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well.1 The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9 and 0.91 documents in June and October of 1996. During 1996, the UML authors invited

and received feedback from the general community. They incorporated this feedback, but it was clear that additional focused attention was still required. While Rational was bringing UML together, efforts were being made on achieving the broader goal of an industry standard modeling language. In early 1995, Ivar Jacobson (then Chief Technology Officer of Objectory) and Richard Soley (then Chief Technology Officer of OMG) decided to push harder to achieve standardization in the methods marketplace. In June 1995, an OMG-hosted meeting of all major methodologists (or their representatives) resulted in the first worldwide agreement to seek methodology standards, under the aegis of the OMG process During 1996, it became clear that several organizations saw UML as strategic to their business. A Request for Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to join forces around producing a joint RFP response. Rational established the UML Partners consortium with several organizations willing to dedicate resources to work toward a strong UML 1.0 definition. Those contributing most to the UML 1.0 definition included: Digital Equipment Corp., HP, iLogix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, and Unisys. This collaboration produced UML 1.0, a modeling language that was well defined, expressive, powerful, and generally applicable. This was submitted to the OMG in January 1997 as an initial RFP response In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam also submitted separate RFP responses to the OMG. These companies joined the UML partners to contribute their ideas, and together the partners produced the revised UML 1.1 response. The focus of the UML 1.1 release was to improve the clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. It was submitted to the OMG for their consideration and adopted in the fall of 1997.1

What is UML:
The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software. Goals of UML The primary goals in the design of the UML were: 1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. 2. Provide extensibility and specialization mechanisms to extend the core concepts.

3. Be independent of particular programming languages and development processes. 4. Provide a formal basis for understanding the modeling language. 5. Encourage the growth of the OO tools market. 6. Support higher-level development concepts such as collaborations, frameworks, patterns and components. 7. Integrate best practices. Why Use UML? As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs. Types of UML Diagrams: Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools include: Use Case Diagram displays the relationship among actors and use cases.1 Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others. Interaction Diagrams

Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects) Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages. State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions. Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing.

Physical Diagrams

Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time.1 Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units.

Assignment No : 1 Title : To Choose a hypothetical system and write an SRS (system requirement specifications) for the same.

Title : To Choose a hypothetical system and write an SRS (system requirement specifications) for the same. Aim: To study system requirements for the systems like Hotel Management, Hospital Management, Banking System etc. Theory : Write the problem statement in depth by understanding the complete system along with all the details for the same. The software requirements specification (SRS) is one of the oldest requirements gathering processes. Known informally as the "shall statements," the traditional SRS exists in many forms and is still required today for contract work in numerous fields. The SRS was the dominant requirements gathering method for many years. The idea behind the SRS is to create a solution space -- that is, a space in which the development team has set goals but a good amount of latitude in the order and nature of activities by which it achieves those goals. As a result, an SRS typically does not try to specify a single solution, but rather defines a family of possible solutions. The development team then has enough flexibility to innovate efficient ways of solving the problem for which a system is being created. Flexibility is a strength as well as a weakness of the SRS. If a software development team is proficient in the domain for which it is creating a system, it can easily use the SRS to maximize innovation in that domain. In an age when development teams routinely work in domains that are foreign to them, however, the traditional SRS may fall short as a requirements gathering process. The team may not understand the steps that a typical user takes when attempting to deal with normal conditions in a given domain. As a result, the team may specify and create a system that is not optimal for the user community. The traditional SRS is best suited to domains that are well understood and to development teams that are familiar with the domain in which they are working -- or to development environments where outside domain expertise is easily accessible. The SRS allows very few techniques for adjusting the solution space to manage change in the system. A requirement describes a capability that the system must provide; it is either derived directly from user needs or stated in a contract, standard, specification, or other formally imposed document. Examples of requirements include the following: Inputs to the system. Outputs from the system. Functions of the system. Attributes of the system. Example : Request Tracker

10

Purpose of this Document This SRS document describes the function and system requirements of the Request Tracking System project. Request Tracker is a web-based application that will help College lab users/technicians/supervisors report problems and maintain an inventory of the equipment in the labs on the various campuses in college. External Interface Requirements

This Product will require access to a computer, including a mouse, monitor and a keyboard. Internet connection will be required. A Web Browser will be required for the users to access this system.(I.E.4.0 and above or Netscape 4.0 and above) mySQL Database will store the Ticket Information. Detailed Description of Functional Requirements Input of Variables Purpose: Inputs: To provide a method of gathering data from the user. Inputs will be gathered from a web-based form that would be used to authenticate the user.

Data will be read from the fields and validated against a mySQL database. The Processing: data will be stored in a database that will be automatically created on installing the application. Outputs: Based on the role the user will have access to specific functions of the application and would be able to view only certain pages within the application.

Analysis of Inputs Purpose: Inputs: To process the data and categorize the problem report based on date the ticket was posted to RT. The values selected by the user that is the campus, the particular lab, and the machine number.

A user will only be able to post a ticket to the group he belongs to. This group will be the campus that he works on. On filling the form for his particular lab Processing: he will click submit. On submit an e-mail notification will be sent to the technician and the problem will be posted on to the RT website. Outputs: The user enters the problem and clicks submit.

Output Sequence Purpose: To provide the visual representation of the results.

11

Inputs: Processing: Outputs:

User name, password, Lab location, problem about the machine, machine description and location. All the inputs will be through web-based forms. Based on the selections of the campus and the labs the user would be able to view requests dealing with that particular lab. The web pages containing the information about the Labs.

Tutorial Sequence Purpose: Inputs: Outputs: Provide help on using the application. Help Manual Tutorial pages with links.

Processing: Data is returned from a webpage.

Performance Requirements The product will be sensitive to bottlenecks and poor optimization choices, particularly if the number of labs is high (for example, greater than 50) or the total number of tickets is large (for example, greater than 100k). Quality Attributes

Security - The product will use user names and passwords for the access levels. Availability - The product will be accessible from the Internet. Maintainability - Extensive documentation will be provided. Expandability - Super users of the product add users and equipment, give users different levels of access, and create groups. New labs can be added to ensure flexibility. Other requirements: None Conclusion :

12

Assignment No : 2 Title : Draw one or more Use case Diagrams for capturing and representing requirements of the system.

13

Title : Draw one or more Use case Diagrams for capturing and representing requirements of the system. Use case diagram must include template showing descriptions and steps of the use case for various scenarios. Aim: To Draw use case diagrams for system requirements of systems like Hotel Management, Hospital Management, Banking System etc. Theory : A use case is a set of scenarios that describing an interaction between a user and a system. A use case diagram displays the relationship among actors and use cases. The two main components of a use case diagram are use cases and actors.

An actor is represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task. When to Use: Use Cases Diagrams Use cases are used in almost every project. The are helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible. How to Draw: Use Cases Diagrams Use cases are a relatively easy UML diagram to draw, but this is a very simplified example. This example is only meant as an introduction to the UML and use cases. Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps. 1. 2. 3. 4. 5. Browse catalog and select items. Call sales representative. Supply shipping information. Supply payment information. Receive conformation number from salesperson.

These steps would generate this simple use case diagram:

14

This example shows the customer as a actor because the customer is using the ordering system. The diagram takes the simple steps listed above and shows them as actions the customer might perform. The salesperson could also be included in this use case diagram because the salesperson is also interacting with the ordering system. From this simple diagram the requirements of the ordering system can easily be derived. The system will need to be able to perform actions for all of the use cases listed. As the project progresses other use cases might appear. The customer might have a need to add an item to an order that has already been placed. This diagram can easily be expanded until a complete description of the ordering system is derived capturing all of the requirements that the system will need to perform. Use Case Diagram Sample Creating Use Case Diagram for describing the behavior of the target system from an external point of view.

Actor An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corresponding subject). Actors

15

mayrepresent roles played by human users, external hardware, or other subjects.

Extend This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary) use case. The extension takes place at one or more specific extension points defined in the extended use case.

Extension Point

16

An Extension Point is a feature of a use case that identifies a point where the behavior of a use case can be augmented with elements of another (extending) use case.

Include Include is a Directed Relationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case. It is also a kind of Named Element so that it can have a name in the context of its owning use case. The including use case may only depend on the result (value) of the included use case. This value is obtained as a result of the execution of the included use case.

UseCase A UseCase is a kind of behavioured classifier that represents a declaration of an offered behavior. Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors. Use cases define the offered behavior of the subject without reference to its internal structure. These behaviors, involving interactions between the actor and the subject, may result in changes to the state of the subject and communications with its environment. A use case can include possible variations of its basic behavior, including exceptional behavior and error handling.

17

18

Assignment No : 3 Title : Draw activity Diagrams to display either business flows or like flow charts.

19

Title : Draw activity charts.

Diagrams to display either business flows or like flow

Aim: To Draw activity diagrams for system like Hotel Management, Hospital Management, Banking System etc to understand system flow. Theory: Activity Diagram Sample The Activity Diagram can help to describe the flow of control of the target system.

AcceptEventAction

20

AcceptEventAction is an action that waits for the occurrence of an event meeting specified conditions.

Action An action may have sets of incoming and outgoing activity edges that specify control flow and data flow from and to other nodes. An action will not begin execution until all of its input conditions are satisfied. The completion of the execution of an action may enable the execution of a set of successor nodes and actions that take their inputs from the outputs of the action.

ActivityFinal An activity may have more than one activity final node. The first one reached stops all flows in the activity.

DataStore A data store keeps all tokens that enter it, copying them when they are chosen to move downstream. Incoming tokens containing a particular object replace any tokens in the object node containing that object.

DecisionNode A decision node is a control node that chooses between outgoing flows.

21

FlowFinal A flow final destroys all tokens that arrive at it. It has no effect on other flows in the activity.

ForkNode
A fork node has one incoming edge and multiple outgoing edges.

InitialNode
An activity may have more than one initial node.

JoinNode
A join node has multiple incoming edges and one outgoing edge.

MergeNode

22

A merge node is a control node that brings together multiple alternate flows. It is not used to synchronize concurrent flows but to accept one among several alternate flows.

ObjectNode
An object node is an activity node that indicates an instance of a particular classifier, possibly in a particular state, may be available at a particular point in the activity. Object nodes can be used in a variety of ways, depending on where objects are flowing from and to, as described in the semantics section.

SendSignalAction
SendSignalAction is an action that creates a signal instance from its inputs, and transmits it to the target object, where it may cause the firing of a state machine transition or the execution of an activity.

ControlFlow
Objects and data cannot pass along a control flow edge.

ObjectFlow
An object flow models the flow of values to or from object nodes.

Activity
An activity specifies the coordination of executions of subordinate behaviors, using a control and data flow model. The subordinate behaviors coordinated by these models may be initiated because other behaviors in the model finish executing, because objects and data become available, or because events occur external to the flow.

23

ActivityPartition
Partitions divide the nodes and edges to constrain and show a view of the contained nodes. Partitions can share contents. They often correspond to organizational units in a business model. They may be used to allocate characteristics or resources among the nodes of an activity.

InterruptibleActivityRegion
An interruptible region contains activity nodes. When a token leaves an interruptible region via edges designated by the region as interrupting edges, all tokens and behaviors in the region are terminated.

24

ExceptionHandler
An exception handler is an element that specifies a body to execute in case the specified exception occurs during the execution of the protected node

ExpansionRegion
An expansion region is a strictly nested region of an activity with explicit input and outputs (modeled as ExpansionNodes). Each input is a collection of values. If there are multiple input pins, each of them must hold the same kind of collection, although the types of the elements in the different collections may vary. The expansion region is executed once for each element (or position) in the input collection.

Local pre- and postconditions

In CompleteActivities, action is extended to have pre- and postconditions.

25

ParameterSet
An parameter set acts as a complete set of inputs and outputs to a behavior, exclusive of other parameter sets on the behavior

Conclusion:

26

Assignment No : 4 A Title : Draw Basic class Diagrams to identify and describe key concepts like classes, types in your system and their relationships.

27

Title : Draw Basic class Diagrams to identify and describe key concepts like classes, types in your system and their relationships. Aim: To Draw basic class diagrams for system like Hotel Management, Hospital Management, Banking System etc to understand system relationship. Theory: Class diagrams are the backbone of almost every object-oriented method including UML. They describe the static structure of a system. Basic Class Diagram Symbols and Notations Classes represent an abstraction of entities with common characteristics. Associations represent the relationships between classes.

Classes Illustrate classes with rectangles divided into compartments. Place the name of the class in the first partition (centered, bolded, and capitalized), list the attributes in the second partition, and write operations into the third.

Active Class Active classes initiate and control the flow of activity, while passive classes store data and serve other classes. Illustrate active classes with a thicker border.

Visibility Use visibility markers to signify who can access the information contained within a class.

28

Private visibility hides information from anything outside the class partition. Public visibility allows all other classes to view the marked information. Protected visibility allows child classes to access information they inherited from a parent class.

Associations Associations represent static relationships between classes. Place association names above, on, or below the association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the end of an association. Roles represent the way the two classes see each other. Note:It's uncommon to name both the association and the class roles.

Multiplicity (Cardinality) Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class. For example, one company will have one or more employees, but each employee works for one company only.

29

Complex Constraint Constraint Place constraints inside curly braces {}.

Simple Constraint

Conclusion:

30

Assignment No : 4 B Title : To Draw advanced class Diagrams to show advanced relationships, other classifiers like interfaces.

31

Title : To Draw advanced class Diagrams to show advanced relationships, other classifiers like interfaces. Aim: To Draw Advanced class diagrams for system like Hotel Management, Hospital Management, Banking System etc to understand advanced relationship and Classifiers like interfaces. Theory: Class Diagram Sample Class Diagram provides an overview of the target system by describing the objects and classes inside the system and the relationships between them.

Class Class is a kind of classifier whose features are attributes and operations. Attributes of a class are represented by instances of Property that are owned by the class. Some of these attributes may represent the navigable ends of binary associations.

32

Interface An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface.

Package A package is a namespace for its members, and may contain other packages. Only packageable elements can be owned members of a package. By virtue of being a namespace, a package can import either individual members of other packages, or all the members of other packages.

33

Aggregation AggregationKind is an enumeration type that specifies the literals for defining the kind of aggregation of a property.

Association An association specifies a semantic relationship that can occur between typed instances. It has at least two ends represented by properties, each of which is connected to the type of the end. More than one end of the association may have the same type.

Composition AggregationKind is an enumeration type that specifies the literals for defining the kind of aggregation of a property. Indicates that the property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (parts).

Dependency A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).

34

Generalization A generalization is a taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus, the specific classifier inherits the features of the more general classifier.

InterfaceRealization An InterfaceRealization is a specialized Realization relationship between a Classifier and an Interface. This relationship signifies that the realizing classifier conforms to the contract specified by the Interface.

Realization Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

Usage

35

A usage is a relationship in which one element requires another element (or set of elements) for its full implementation or operation. In the metamodel, a Usage is a Dependency in which the client requires the presence of the supplier.

Conclusion:

36

Assignment No : 5 Title : To Draw sequence Diagram with advance notation for your system to show objects and their message exchanges.

37

Title : To Draw sequence Diagram with advance notation for your system to show objects and their message exchanges. Aim: To Draw sequence diagrams for system like Hotel Management, Hospital Management, Banking System etc to show objects and message exchanges. Theory: Sequence diagrams describe interactions among classes in terms of an exchange of messages over time. Basic Sequence Diagram Symbols and Notations

Class roles Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate class roles, but don't list object attributes. Learn how to edit text on a symbol.

38

Activation Activation boxes represent the time an object needs to complete a task.

Messages Messages are arrows that represent communication between objects. Use half-arrowed lines to represent asynchronous messages. Asynchronous messages are sent from an object that will not wait for a response from the receiver before continuing its tasks. Learn how to draw messages.

Various message types for Sequence and Collaboration diagrams

39

Lifelines Lifelines are vertical dashed lines that indicate the object's presence over time. Learn how to attach activation boxes to lifelines.

Destroying Objects Objects can be terminated early using an arrow labeled "< < destroy > >" that points to an X.

40

Loops A repetition or loop within a sequence diagram is depicted as a rectangle. Place the condition for exiting the loop at the bottom left corner in square brackets [ ]. Conclusion :

41

Assignment No : 6 Title : To Draw State Machine Diagram to model the behavior of a single object specifying the sequence of events that an object goes through during its lifetime in response to event message exchanges.

42

Title : To Draw State Machine Diagram to model the behavior of a single object specifying the sequence of events that an object goes through during its lifetime in response to event message exchanges. Aim: To Draw State Machine diagrams for system like Hotel Management, Hospital Management, Banking System etc to show objects and message exchanges. Theory: State Machine Diagram Sample State Machine diagram can show the different states of an entity also how an entity responds to various events by changing from one state to another.

Choice pseudo state A choice vertices which, when reached, result in the dynamic evaluation of the guards of the triggers of its outgoing transitions. This realizes a dynamic conditional branch. It allows splitting of transitions into multiple outgoing paths such that the decision on which path to take may be a function of the results of prior actions performed in the same run-to-completion step.

Composite state

43

A composite state is either a simple composite state (with just one region) or an orthogonal state (with more than one region).

Entry point An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region.

Exit point An exit point pseudostate is an exit point of a state machine or composite state. Entering an exit point within any region of the composite state or state machine referenced by a submachine state implies the exit of this composite state or submachine state and the triggering of the transition that has this exit point as source in the state machine enclosing the submachine or composite state.

44

Final state A special kind of state signifying that the enclosing region is completed. If the enclosing region is directly contained in a state machine and all other regions in the state machine also are completed, then it means that the entire state machine is completed.

45

Initial pseudo state An initial pseudostate represents a default vertex that is the source for a single transition to the default state of a composite state. There can be at most one initial vertex in a region. The initial transition may have an action.

Junction pseudo state A junction vertices are semantic-free vertices that are used to chain together multiple transitions. They are used to construct compound transition paths between states.

Region

46

A region is an orthogonal part of either a composite state or a state machine. It contains states and transitions.

Simple state A simple state is a state that does not have substates, i.e. it has no regions and it has no submachine state machine.

State list A state models a situation during which some (usually implicit) invariant condition holds. The invariant may represent a static situation such as an object waiting for some external event to occur.

47

Terminate node Entering a terminate pseudostate implies that the execution of this state machine by means of its context object is terminated. The state machine does not exit any states nor does it perform any exit actions other than those associated with the transition leading to the terminate pseudostate.

Submachine state A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine.

48

Transition A transition is a directed relationship between a source vertex and a target vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to an occurrence of an event of a particular type.

Conclusion:

49

Assignment No : 7 Title : To Draw Component Diagram assuming that you will build your system reusing existing components along with few new ones.

50

Title : To Draw Component Diagram assuming that you will build your system reusing existing components along with few new ones. Aim: To Draw Component diagram for system like Hotel Management, Hospital Management, Banking System etc by using existing components. Theory: The Component Diagram helps to model the physical aspect of an Object-Oriented software system.

Component A component is a subtype of Class which provides for a Component having attributes and operations, and being able to participate in Associations and Generalizations. A Component may form the abstraction for a set of realizingClassifiers that realize its behavior. In addition, because a Class itself is a subtype of an EncapsulatedClassifier, a Component may optionally have an internal structure and own a set of Ports that formalize its interaction points.

51

Component implements Interface An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface.

Component has provided Port (typed by Interface) Ports represent interaction points between a classifier and its environment. The interfaces associated with a port specify the nature of the interactions that may occur over a port. The required interfaces of a port characterize the requests which may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port.

Component uses Interface An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface.

Component has required Port (typed by Interface) Ports represent interaction points between a classifier and its environment. The interfaces associated with a port specify the nature of the interactions that may occur over a port. The required interfaces of a port characterize the requests which may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port.

52

Component has complex Port (typed by provided and required Interfaces) Ports represent interaction points between a classifier and its environment. The interfaces associated with a port specify the nature of the interactions that may occur over a port. The required interfaces of a port characterize the requests which may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port.

Assembly connector An assembly connector is a connector between two components that defines that one component provides the services that another component requires. An assembly connector is a connector that is defined from a required interface or port to a provided interface or port.

Conclusion:

53

Assignment No : 8 Title : To Draw Deployment Diagram to model the runtime architecture of your system.

54

Title : To Draw Deployment Diagram to model the runtime architecture of your system. Aim: To Draw Deployment diagram for system like Hotel Management, Hospital Management, Banking System. Theory: The Deployment Diagram also helps to model the physical aspect of an Object-Oriented software system.

Node In the metamodel, a Node is a subclass of Class. It is associated with a Deployment of an Artifact. It is also associated with a set of Elements that are deployed on it. This is a derived association in that these PackageableElements are involved in a Manifestation of an Artifact that is deployed on the Node. Nodes may have an internal structure defined in terms of parts and connectors associated with them for advanced modeling applications.

55

Association An association specifies a semantic relationship that can occur between typed instances. It has at least two ends represented by properties, each of which is connected to the type of the end. More than one end of the association may have the same type.

Dependency A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).

Conclusion:

56

VIIT, Pune

Lab Manual

Title: Distribution List

Section: Annex-A / ISO Clause: 4

Copy No.
01 02 03 04 05 06 07

Copy Holder
M.R. H.O.D. (Computer) Practical Incharge

Rev No:0, Dt-2.1-.2006 57

VIIT, Pune

Lab Manual

Title: Revision Record

Section: Annex-B / ISO Clause: 8.2.3

Sr. No.

Section

Old revi sion / Date

New

Reason for rev Revision isio n/

Original issue

Date
NA

(1)

All

NA

58 Rev No:0, Dt-2.1-.2006