Zamin Endathur, Madurantakam, Kancheepuram District – • + /92 • soundofheaven.info CS – OOAD LAB MANUAL. VI SEMESTER . Ooad lab manual(original). 1. - 13OBJECTORIENTEDANALYSISANDDESIGN (O.O.A.D) SUBJECT CODE: DEPARTMENT OF. OOAD Lab manual. Click Here For Downloading OOAD or Case Tool Lab manual. COMPUTER NETWORKS LAB VIVA QUESTIONS. CS
|Language:||English, Spanish, Portuguese|
|Genre:||Children & Youth|
|ePub File Size:||23.59 MB|
|PDF File Size:||17.76 MB|
|Distribution:||Free* [*Regsitration Required]|
Object orientation analysis and design with UML. Final OOAD Lab Manual for 3rd Year CSE by Gopi. Object-Oriented Software Development Using UML READ By soundofheaven.info Final OOAD Lab Manual for 3rd Year CSE by Gopi - Free download as Word Doc .doc), PDF File .pdf), Text File .txt) or read online for free. OOAD lab manual - Free download as PDF File .pdf), Text File .txt) or read online for free.
Drawing these entity types incorrectly will likely confuse readers of your class diagram, and the ensuing code will probably not meet requirements. Interface Dependencies: Look at this set of classes as a whole, split classes that have too many responsibilities into smaller abstractions, collapse tiny classes that have trivial responsibilities into larger ones, and reallocate responsibilities so that each abstraction reasonably stands on its own. Activity diagram transitions are analogous to use case diagram communications. Third normal form states that a table should be in second normal form and no attribute should transitively depend on the primary key. An association is a generic relationship between two classes and is shown as a thin line connecting two classes. Record borrowing.
Component 7. It describes the externally visible behavior of that element. Define a society of roles and other elements. Provide cooperative behavior. Capture structural and behavioral dimensions. A set of scenarios tied together by a common user goal. Provides a structure for behavioral things. Realized through a collaboration usually realized by a set of actors and the system to be built. Can initiate control activity. Replaceable part of a system. Components can be packaged logically.
Conforms to a set of interfaces. Provides the realization of an interface. Represents a physical module of code. Element that exists at run time. Represents a computational resource. Generally has memory and processing power. These are Dynamic parts of UML models: Is a behavior of a set of objects comprising of a set of messages exchanges within a particular context to accomplish a specific purpose.
Is a behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events. There is only one primary kind of group thing:. Packages - General purpose mechanism for organizing elements into groups. Note A note is simply a symbol for rendering constraints and comments attached to an element or collection of elements.
Is a best expressed in informal or formal text. Dependency 2. Association 3. Generalization 4. Realization These relationships tie things together. It is a semantic connection among elements. These relationships are the basic relational building blocks of the UML. Dependency Is a semantic relationship between two things in which a change to one thing the independent thing may affect the semantics of the other thing the dependent thing.
Association Is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation Is a special kind of association. It represents a structural relationship between the whole and its parts.
Represented by black diamond. Realization a semantic relationship between two elements, wherein one element guarantees to carry out what is expected by the other element. A diagram is the graphical presentation of a set of elements. Represented by a connected graph: Vertices are things; Arcs are behaviors. Basically we will explain UMLs below diagrams: Class Diagram Class Diagrams describe the static structure of a system, or how it is structured rather than how it behaves.
A class diagram shows the existence of classes and their relationships in the logical view of a system These diagrams contain the following elements. Classes and their structure and behavior Association, aggregation, dependency, and inheritance relationships Multiplicity and navigation indicators Role names These diagrams are the most common diagrams found in O-O modeling systems.
Object Diagrams Shows a set of objects and their relationships. A static snapshot of instances. Object Diagrams describe the static structure of a system at a particular time. Whereas a class model describes all possible situations, an object model describes a particular situation. Object diagrams contain the following elements: Objects which represent particular entities. These are instances of classes. Links which represent particular relationships between objects.
These are instances of associations. Use case diagrams Use Case Diagrams describe the functionality of a system and users of the system. These diagrams contain the following elements: Use Cases: Use case diagrams are used during requirements elicitation and analysis as a graphical means of representing the functional requirements of the system.
A use case diagram is a visual representation of the relationships between actors and use cases together that documents the systems intended behavior. Use cases are developed during requirements elicitation and are further refined and corrected as they are reviewed during analysis. Use cases are also very helpful for writing acceptance test cases. In UML, a use case is represented as an ellipse. An actor represents whoever or whatever person, machine, or other interacts with the system.
The actor is not part of the system itself and represents anyone or anything that must interact with the system to: Input information to the system; Receive information from the system; or Both input information to and receive information from the system. Arrows and lines are drawn between actors and use cases and between use cases to show their relationships. The default relationship between an actor and a use case is the communicates relationship,denoted by a line.
When a line or an arrow is drawn on a diagram and there is no label on the arrow, it is, by default, a communicates relationship. Sequence diagrams Sequence Diagrams describe interactions among classes. Related titles. Jump to Page. Search inside document. Batch - I Batch - II REG NO DEPT: CSE Roll. NO 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 REG NO Roll. CSE The applications method recommends the use of static and dynamic views of a logical model and a physical model to capture the in-process products of object-oriented analysis and design.
CSE The component view addresses the ease of development management of software assets, reuse, subcontracting and of the shelf components. EX NO: CSE This module enables the end users to register themselves to the online quiz competition through two-way communication between the coordinator and the participant.
General view DEPT: CSE Ex. Display the book details on the screen. Issue the book. CSE Librarian Student 9: Enter author name Issue the book 1: Enter Login Details 6: CSE 1: View schedule 2: Add appointment Person Appointment Control 5: If yes, create appointment 3: Check availability 6: Reschedule 7: Prepare for orde r Config wi ndow Order 4: Display order Orde r wi ndow 6: Store order 5: Submit order 1: Open new 2: Accep t c onfig 7: Link customer Payment 8: Customer public void browsecatalog DEPT: Customer public void setAddrToShip public void browsecatalog public void deleverItem public void shipm entD etails public void getAddrToShop public void displaycatalog public void getC reditR ating public void selectItem public void setC reditC ard public void rem oveOrder public void setC rediting int val: Shoppingcart public void rejected public void authorize public void authorizedC harge: Kamal Kannan.
Aravind Siva. Vengatraman Pondicherry. Pon Venkatesh. Abdisamad Muse Hassan. Selva Kanmani. Lavanya Amirthaligam. Manoj Mahajan. Anand Dama. Arun Kumar. Akshay Kumar Chandran. Bala Vishnu. Devi Ram. Ragavendhran N. Girish Kumar Nistala. Journal of Computer Applications.
Sathish Kumar. Popular in Software Engineering. Mario Leonel Torres Martinez. Suren Markosov. Rashid Iqbal. Christian Diaz. Alexander Cordero. Rodriguez Arthurs. Models document the decisions we have made. It has been used effectively for domains such as o Enterprise information systems. A library lends books and magazines to members who are registered in the system.
It also handles the purchases of new books and magazines for the library. Popular titles are brought in multiple copies. Books and magazines are removed when they are out dated or in poor conditions.
A member can reserve a book or a magazine that is not currently available, so that it can be notified to the reserved person when it is return or purchased by library. The library can create, update or delete information about the books or delete information about the books or members and borrowings.
A use case diagram is a diagram that shows a set of use cases and actors and their relationships. Use case diagrams may also contain packages, which are used to group elements of your model into larger chants. Use case diagram is used in one of two ways 1 To model the context of a system. Modeling Techniques: Primary Actor: Member Secondary Actor: Librarian The person who are interested can take the membership in the library and can use for services.
All the information about members is maintained by the system. Flow of Events: The member asks the librarian for membership to library. Then librarian verifies the member is from staff or is a student. If member is not a student or staff then librarian rejects his request. If the member is either from staff or a student then the gives a form to fill up with his details. When the member finishes the form the librarian issues membership. The person who is requesting for a membership should be a staff or student.
Post condition: Primary actor: Library staff Secondary actor: The library staff issues the requested book to the member by specifying issue date and return date. The library assistant fills the form by selecting book requested by the student and requested for a search in the current list.
If the book is found in the list, mark the book in student account by student id. If the book is marked under issue, indicate the same to the student.
If book not found in the list indicates the same to the student. The member returns the books to the library. The librarian receives the books and checks the returned date. If the return date does not exceeds the specified date then the takes the books and the member is capable for taking other books.
If the return date exceeds the specified date then librarian calculates the fines based on exceed time and collects money from the member. When the member pays the fine then librarian gives a slip[ specifying that fine is paid and hence member can access the books.
The library clerk checks for the status of a book. Member Secondary actor: Requesting a book taking place between a member and library staff. Member requests for book from the library.
Member request a book in the library. Librarian checks for membership if book is available issues book to member. If book that is requested is not available it to member.
Librarian records the transaction of book. The person making the request must be a member of the library. NO Flow of Events: The librarian places the book in a particular order according to the subjects. The librarian checks whether the books are placed in an order. Librarian Secondary actor: NO The library clerk displays the book in an order according to the subjects.
NO Post condition: Library staff. The book taken by the member is returned back after the return date has been completed. The member checks for return date of a book and then the returns the book.
A member can reserve a book or magazine that is not currently available so that when it is reserved or purchased by library the person is notified. The members who have membership in the library requests a book. The librarian checks the book is currently available or not. If the book is available then librarian issues the book to the member. If the book is not available currently then librarian reserves the specified book in account of person who requested it.
When the book is available then librarian notifies the person who requested it and informs to the person. A requesting person must be member of library. Library clerk Secondary actor: The members who have a book already issued by librarian can renewal the book to library. The member brings back the book to library whenever the return date of book exceeds. The librarian checks the return date and book condition and renew.
The person should be issued by a book. Terms and Concepts A class is a description of a set of objects that share the same attributes, operations, relationships and semantics. Graphically, a class is rendered as a rectangle. Class diagram commonly contains the following things.
Class diagrams may also contain packages or subsystems both of which are used to group elements of your model into layer chunks. Class diagrams are used in one of 3 ways. Modeling the Vocabulary of a System. Modeling the Distribution of Responsibilities in a System. Modeling Nonsoftware Things.
Common Modeling Techniques You'll use classes most commonly to model abstractions that are drawn from the problem you are trying to solve or from the technology you are using to implement a solution to that problem. Each 9. Modeling Nonsoftware Things To model the vocabulary of a system, Identify those things that users or implementers use to describe the problem or solution.
Use CRC cards and use case-based analysis to help find these abstractions. For each abstraction, identify a set of responsibilities.
Make sure that each class is crisply defined and that there is a good balance of responsibilities among all your classes. Provide the attributes and operations that are needed to carry out these responsibilities for each class. Modeling the Distribution of Responsibilities in a System To model the distribution of responsibilities in a system, Identify a set of classes that work together closely to carry out some behavior.
Identify a set of responsibilities for each of these classes. Look at this set of classes as a whole, split classes that have too many responsibilities into smaller abstractions, collapse tiny classes that have trivial responsibilities into larger ones, and reallocate responsibilities so that each abstraction reasonably stands on its own.
Consider the ways in which those classes collaborate with one another, and redistribute their responsibilities accordingly so that no class within a collaboration does too much or too little. Model the thing you are abstracting as a class. If you want to distinguish these things from the UML's defined building blocks, create a new building block by using stereotypes to specify these new semantics and to give a distinctive visual cue.
If the thing you are modeling is some kind of hardware that itself contains software, consider modeling it as a kind of node, as well, so that you can further expand on its structure. Terms and Concepts An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose. A message is a specification of a communication A sequence diagram is an interaction diagram that emphasizes the time ordering of messages.
A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages. Interaction diagrams commonly contain Objects Links Messages Interaction diagrams are used in two ways: To model a flow of control, Set the context for the interaction, whether it is the system as a whole, a class, or an individual operation.
Set the stage for the interaction by identifying which objects play a role; set their initial properties, including their attribute values, state, and role. If your model emphasizes the structural organization of these objects, identify the links that connect them, relevant to the paths of communication that take place in this interaction.
Specify the nature of the links using the UML's standard stereotypes and constraints, as necessary. In time order, specify the messages that pass from object to object. As necessary, distinguish the different kinds of messages; include parameters and return values to convey the necessary detail of this interaction. Also to convey the necessary detail of this interaction, adorn each object at every moment in time with its state and role. Book issue:. Modeling Flows of Control by Time Ordering To model a flow of control by time ordering, Set the context for the interaction, whether it is a system, subsystem, operation, or class, or one scenario of a use case or collaboration.
Set the stage for the interaction by identifying which objects play a role in the interaction. Lay them out on the sequence diagram from left to right, placing the more important objects to the left and their neighboring objects to the right. Set the lifeline for each object. In most cases, objects will persist through the entire interaction.
For those objects that are created and destroyed during the interaction, set their lifelines, as appropriate, and explicitly indicate their birth and death with Starting with the message that initiates this interaction, lay out each subsequent message from top to bottom between the lifelines, showing each message's properties such as its parameters , as necessary to explain the semantics of the interaction.
If you need to visualize the nesting of messages or the points in time when actual computation is taking place, adorn each object's lifeline with its focus of control. If you need to specify time or space constraints, adorn each message with a timing mark and attach suitable time or space constraints.
If you need to specify this flow of control more formally, attach pre- and postconditions to each message. An is an ongoing nonatomic execution within a state machine. Activities ultimately result in some action, which is made up of executable atomic computations that result in a change in state of the system or the return of a value.
Actions encompass calling another operation, sending a signal, creating or destroying an object, or some pure computation, such as evaluating an expression. Graphically, an activity diagram is a collection of vertices and arcs. Swim lines: Member, Find book on shelf. Wait in queue. Record return. Record borrowing. Prepare for next member Decisions: Is borrower Is returner.
Member visits the library either to borrow a book or return a book. If member needs to borrow a book then he finds book on shelf after finding the book he wait in queue. If member needs to return book then also be waits in queue. Librarian checks the person in queue borrower or returner. If member is returner then librarian records return transaction and put book on the shelf. If member is borrower then the librarian issues the book to member and records borrowing transactions.
If the members work is completed the librarian prepares for next member, until waiting queue is completed. When waiting queue is empty then it is final state of activity diagram. For nontrivial systems, it's impossible to show all interesting workflows in one diagram.
Select the business objects that have the high-level responsibilities for parts of the overall workflow. These may be real things from the vocabulary of the system, or they may be more abstract. In either case, create a swimlane for each important business object. Identify the preconditions of the workflow's initial state and the postconditions of the workflow's final state.
This is important in helping you model the boundaries of the workflow. Beginning at the workflow's initial state, specify the activities and actions that take place over time and render them in the activity diagram as either activity states or action states.
For complicated actions, or for sets of actions that appear multiple times, collapse these into activity states, and provide a separate activity diagram that expands on each. Render the transitions that connect these activity and action states. Start with the sequential flows in the workflow first, next consider branching, and only then consider forking and joining. If there are important objects that are involved in the workflow, render them in the activity diagram, as well.
Show their changing values and state as necessary to communicate the intent of the object flow. Modeling an Operation To model an operation, Collect the abstractions that are involved in this operation. This includes the operation's parameters including its return type, if any , the attributes of the enclosing class, and certain neighboring classes. Identify the preconditions at the operation's initial state and the postconditions at the operation's final state.
Also identify any invariants of the enclosing class that must hold during the execution of the operation. Beginning at the operation's initial state, specify the activities and actions that take place over time and render them in the activity diagram as either activity states or action states. Use branching as necessary to specify conditional paths and iteration. Only if this operation is owned by an active class, use forking and joining as necessary to specify parallel flows of control.
Terms and Concepts A state machine is a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events. A state is a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.
In this state chart diagram contains: States, transitions, and activities Modeling the lifetime of an object Creating well-structured algorithms. To model the lifetime of an object, Set the context for the state machine, whether it is a class, a use case, or the system as a whole. If the context is a class or a use case, collect the neighboring classes, including any parents of the class and any classes reachable by associations or Dependences.
These neighbors are candidate targets for actions and are Candidates for including in guard conditions. Theoretically, every object in the system may be a participant in a model of the system's lifetime, and except for the most trivial systems, a complete model would be intractable. Establish the initial and final states for the object. To guide the rest of your model, possibly state the pre- and post conditions of the initial and final states, respectively.
Decide on the events to which this object may respond. If already specified, you'll find these in the object's interfaces; if not already specified, you'll have to consider which objects may interact with the object in your context, and then which events they may possibly dispatch.
Starting from the initial state to the final state, lay out the top-level states the object may be in. Connect these states with transitions triggered by the appropriate events. Continue by adding actions to these transitions. Identify any entry or exit actions especially if you find that the idiom they cover is used in the state machine.
Expand these states as necessary by using substates. Check that all events mentioned in the state machine match events expected by the interface of the object. Similarly, check that all events expected by the interface of the object are handled by the state machine.
Finally, look to places where you explicitly want to ignore events. Check that all actions mentioned in the state machine are sustained by the relationships, methods, and operations of the enclosing object.
Trace through the state machine, either manually or by using tools, to check it against expected sequences of events and their responses. Be especially diligent in looking for unreachable states and states in which the machine may get stuck.
After rearranging your state machine, check it against expected sequences again to ensure that you have not changed the object's semantics. Modeling the Lifetime of An Object. When member needs to borrow a book then librarian checks whether copies of book are available or not. There are two states borrowable and not borrowable states. The member returns the copy or book to the librarian then it goes under the state of borrowable. The member borrows a book which was not the last copy then also it goes to under the state of borrowable.
The member borrows a book which was the last it goes under the not borrowable state. The member if reserves the book which was not there then it goes under the not borrowable state.
Terms and Concepts A component diagram shows a set of components and their relationships. Graphically, a component diagram is a collection of vertices and arcs. Component diagrams commonly contain Components Interfaces Dependency, generalization, association, and realization relationships Components:.
Modeling source code Modeling executable releases Modeling physical databases Modeling adaptable systems Forward and reverse engineering. To model source code With most contemporary object-oriented programming languages, you'll cut code using integrated development environments that store your source code in files.
You can use component diagrams to model the configuration management of these files, which represent workproduct components. To model executable releases A release is a relatively complete and consistent set of artifacts delivered to an internal or external user.
In the context of components, a release focuses on the parts necessary to deliver a running system. When you model a release using component diagrams, you are visualizing, specifying, and documenting the decisions about the physical parts that constitute your software that is, its deployment components.
To model physical databases. Think of a physical database as the concrete realization of a schema, living in the world of bits. Schemas, in effect, offer an API to persistent information; the model of a physical database represents the storage of that information in the tables of a relational database or the pages of an Object-oriented database.
You use component diagrams to represent these and other kinds of Physical databases. To model adaptable systems Some systems are quite static; their components enter the scene, participate in an execution, and then depart. Other systems are more dynamic, involving mobile agents or components that migrate for purposes of load balancing and failure recovery. You use component diagrams in conjunction with some of the UML's diagrams for modeling behavior to represent these kinds of systems.
Common modeling techniques: Modeling Source Code To model a source code, Either by forward or reverse engineering, identify the set of source code files of interest and model them as components stereotyped as files. For larger systems, use packages to show groups of source code files. Consider exposing a tagged value indicating such information as the version number of the source code file, its author and the date it was last changed. Use tools to manage the value of this tag.
Model the compilation dependencies among these files using dependencies.
Again, use tools to help generate and manage these dependencies. Modeling an Executable Release To model an executable release, Identify the set of components youd like to model. Typically, this will involve some or all the components that live on one node, or the distribution of these sets of components across all the nodes in the system.
Consider the stereotype of each component in this step. For most systems, youll find a small number of different kinds of components such as executables, libraries, tables, files and documents.
You can use the UMLs extensibility mechanism to provide visual cues for these stereotypes. For each component in this set, consider its relationship to its neighbors. Most often, this will involve interfaces that are exported realized by certain If you want to expose the seams in your system, model these interfaces explicitly.
If you want your model at a higher level of abstraction, elide these relationships by showing only dependencies among the components. Modeling a Physical Database To model a physical database, Identify the classes in your model that represent your logical database schema. Select a strategy for mapping these classes to tables. You will also want to consider the physical distribution of your databases. Your mapping strategy will be affected by the location in which you want your data to live on your deployed system.
To visualize, specify, construct, and document your mapping, create a component diagram that contains components stereotyped as tables. Where possible, use tools to help you transform your logical design into a physical design. Modeling Adaptable Systems To model an adaptable system, Consider the physical distribution of the component that may migrate from node to node. You can specify the location of a component instance by marking it with a location tagged value, which you can then render in a component diagram although, technically speaking, a diagram that contains only instances is an object diagram.
If you want to model the actions that cause a component to migrate, create a corresponding interaction diagram that contains component instances. You can illustrate a change of location by drawing the same instance more than once, but different values for its location tagged value. Forward and Reverse Engineering To forward engineer a component diagram, For each component, identify the classes or collaborations that the component implements.
Choose the target for each component. Your choice is basically between source code a form that can be manipulated by development tools or a binary library or executable a form that can be dropped into a running system. Use tools to forward engineer your models. To reverse engineer a component diagram, Choose the target you want to reverse engineer.
Source code can be reverse engineered to components and the classes. Binary libraries can be reverse engineered to uncover their interfaces. Executables can be reverse engineered the least. Using a tool, point to the code youd like to reverse engineer. Use your tool to generate a model or to modify an existing one that was previously forward engineered. Using your tool, create a component diagram by querying the model. For example, you might start with one or more component, then expand the diagram by following relationships or neighboring components.
Expose or hide the details of the contents of this component diagram as necessary to communicate your intent. Terms and Concepts A deployment diagram is a diagram that shows the configuration of run time processing nodes and the components that live on them.
Graphically, a deployment diagram is a collection of Deployment diagrams commonly contain Nodes Dependency and association relationships. To model embedded systems An embedded system is a software-intensive collection of hardware that interfaces with the physical world.
Embedded systems involve software that controls devices such as motors, actuators, and displays and that, in turn, is controlled by external stimuli such as sensor input, movement, and temperature changes.
You can use deployment diagrams to model the devices and processors that comprise an embedded system. You can model the topology of such systems by using deployment diagrams.
To model fully distributed systems At the other end of the continuum of distributed systems are those that are widely, if not globally, distributed, typically encompassing multiple levels of servers. Such systems are often hosts to multiple versions of software components, some of which may even migrate from node to node. Crafting such systems requires you to make decisions that enable the continuous change in the system's topology.
You can use deployment diagrams to visualize the system's current topology and distribution of components to reason about the impact of changes on that topology. Common Modeling systems: Modeling an Embedded System To model an embedded system, Identify the devices and nodes that are unique to your system. Provide visual cues, especially for unusual devices, by using the UMLs extensibility mechanisms to define system specific stereotypes with appropriate icons.
At the very least, youll want to distinguish processors which contain. Model the relationships among these processors and devices in a deployment diagram. Similarly, specify the relationship between the components in your systems deployment view. As necessary, expand on any intelligent devices by modeling their structure with a more detailed deployment diagram. Highlight those devices that are germane to the behavior of your system.
For example, youll want model special devices, such as credit card readers, and display devices other than monitors, because their placement in the systems hardware topology are likely to be architecturally significant. Provide visual cusses for these processors and devices via stereotyping. Model the topology of these modes in a deployment diagram. Similarly, specify the relationship between the components in your systems implementation view and the nodes in your systems deployment view.
Modeling a Fully Distributed System: If you need to reason about the performance of the systems network or the impact of changes to the network, be sure to model this communication devices to the level of detail sufficient to make these assessments.
Pay close attention to logical groupings of nodes, which you can specify by using packages. Model these devices and processors using deployment diagrams.