OBJECT ORIENTED SOFTWARE ENGINEERING Q1. What are the types of integration testing? There are some different types of integration testing that can be conducted, below is a list of the different integration testing types; Big Bang The way this integration testing type works is, most or all of the modules are integrated together to form nearly a complete system. This is very similar to system testing as this basically has a whole system before starting the testing. There are not many advantages of the big bang integration; the only advantage is that for a smaller system this will be the ideal integration testing technique. The disadvantages is that you would have to wait for all the modules to be integrated in order to do big-bang testing so there will be quite a lot of delay. Any errors are identified at a very late stage and it is very hard to indentify the fault. It is very difficult to be sure that all testing has been done before product release. Bottom Up Testing is an approach to integrated testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested. All the bottom or low-level modules, procedures or functions are integrated and then tested. After the integration testing of lower level integrated modules, the next level of modules will be formed and can be used for integration testing. This approach is helpful only when all or most of the modules of the same development level are ready. This method also helps to determine the levels of software developed and makes it easier to report testing progress in the form of a percentage. Top Down Testing is an approach to integrated testing where the top integrated modules are tested and the branch of the module is tested step by step until the end of the related module. Sandwich Testing is an approach to combine top down testing with bottom up testing. Q2. What are the Techniques for requirements elicitation? Sol: Some techniques for requirement elicitation are: Interview(Question Answers) Used for eliciting detailed information from an individual • For the small projects – may be used as the only requirement elicitation technique • For large projects – usually a part of some high-level elicitation technique • Interviewing is not simply a matter of asking questions; it requires development of some general social skills, the ability to listen, and knowledge of a variety of interviewing tactics • Overcomes articulation problems and communication barriers Four phases of interview are: • Identifying candidates • Preparing for an interview • Conducting the interview • Following up Brainstorming Brainstorming is a group or individual creativity technique by which efforts are made to find a conclusion for a specific problem by gathering a list of ideas spontaneously contributed by its member(s) Following these two principles were his four general rules of brainstorming, established with intention to : reduce social inhibitions among group members, stimulate idea generation increase overall creativity of the group. FAST(Facilitated Application Specification Technique) The objective is to close the gap between what the developers intend and what users expect. It is a team-oriented approach for gathering requirements. This encourages creation of joint team of customers and developers who work together to identify the problem, purpose elements of solution, negotiate different approaches and specify a preliminary set of solution. Basic Guidelines of FAST Meeting are: o o o A meeting is conducted at a neutral site. Rules for preparation and participation are established. An agenda is suggested that is formal enough to cover all important points but informal enough to encourage free flow of ideas. o o o A “Facilitator” controls the meeting A ‘Definition mechanism’ ( like work sheets, wall stickers etc..) is used. The goal is to identify the problem, purpose elements of the solution, negotiate different approaches and specify a preliminary set of solution in an atmosphere conducive to accomplishment of the goal. QFD (Quality Function deployment) Quality function deployment (QFD) is a “method to transform qualitative user demands into quantitative parameters, to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts Software requirements can be classified into three categories: Normal, exciting and expected . 1.Normal Requirements are what the stakeholders communicate during traditional facilitated sessions or in interviews. They cover the base functionality of the application. These requirement contribute proportionally to customer satisfaction and expectations. 2. Expected requirements: These are implicit to the product or system and may be so fundamental that the customer may not explicitly state them. Their absence will cause significant dissatisfaction. 3.Exciting Requirements: are aspects which the users do not expect. Often exciting requirements involve innovation of the business process or new ways of handling functionality. Use Cases In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in Unified Modeling Language (UML) as an "actor") and a system, to achieve a goal. The actor can be a human or an external system. A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but need not be human: "An actor might be a person, a company or organization, a computer program, or a computer system — hardware, software, or both. Q3. Explain the requirement elicitation activities. Requirements Elicitation Activities are o o o o o Identifying Actors Identifying Use Cases Identifying Relationships among Actors and Use Cases Identifying Initial Analysis Objects Identifying Nonfunctional Requirements o o Identifying Scenarios Refining Use Cases Identifying Actors Actors represent roles One person can have several roles Many persons can have the same role In companies, roles usually exist before system is built. Identifying Scenarios: A scenario is a narrative description of what people do and experience as they try to make computer systems and applications. Types of scenarios: o Visionary scenario :Used to describe a future system . o As- is scenario: Describes current situation o Evaluation Scenario: describes task against which system is to be evaluated o Training scenarios: step by step instructions desgined to hand-hold the user through common tasks. Identifying Use Cases o Scenarios are generalized to high-level use cases o Name - A verb describing what the actor wants to accomplish o Initiating actor - Helps to clarify roles - Helps identifying previously overlooked actors o High-level description - Entry and exit conditions (identify missing cases) - Event flow (define system boundary) - Quality requirements (elicit nonfunctional requirements) Refining Use Cases Many use cases are rewritten several times Focus: completeness and correctness o o o o o o Activities during refinement Add details to use cases Specify low-level sequences of interactions Specify access rights (which actor can invoke which use case) Identify missing exceptions and specify handling Factor out common functionality Identifying Relationships among Actors and Use Cases Relationships among actors and use cases reduce systems complexity. An association relationship may exist between actor and use case Use include relationships to factor out commonly occurring normal activities that are common to multiple use-cases. Included use-cases are often capable of standing alone as use-cases, and are usually invoked from other use-cases at predictable points. Example: Printing. Use extend relationships to document unusual, exceptional, error, and rarely occurring usecases. Extend use-cases generally cannot stand alone, and in general could be invoked from any point in a number of use cases. Example: Power failure. Identifying Nonfunctional Requirements Nonfunctional requirements are defined together with functional requirements because of dependencies Basic non functional requirement deal with issues like: o o o o o o o Quality attributes Constraints Usability Reliability Performance Portability Maintainability Identifying initial analysis objects We need to establish a clear terminology to be used by the developer and users. So, developers identify the participating objects for each use case. The identification of participating objects results in an initial analysis object model. Q4. What are Structural things in UML. Things in the UML There are four kinds of things in the UML: 1. 2. 3. 4. Structural things Behavioral things Grouping things Annotational things These things are the basic object-oriented building blocks of the UML. You use them to write well-formed models. Structural Things Structural things are the nouns of UML models. These are the mostly static parts of a model, representing elements that are either conceptual or physical. Collectively, the structural things are called classifiers. A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations, Class An interface is a collection of operations that specify a service of a class or component. An interface therefore describes the externally visible behavior of that element. An interface might represent the complete behavior of a class or component or only a part of that behavior. An interface defines a set of operation specifications (that is, their signatures) but never a set of operation implementations. The declaration of an interface looks like a class with the keyword «interface» above the name; attributes are not relevant, except sometimes to show constants. An interface rarely stands alone, however. An interface provided by a class to the outside world is shown as a small circle attached to the class box by a line. An interface required by a class from some other class is shown as a small semicircle attached to the class box by a line, Collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements. Collaborations have structural, as well as behavioral, dimensions. A given class or object might participate in several collaborations. These collaborations therefore represent the implementation of patterns that make up a system. Graphically, a collaboration is rendered as an ellipse with dashed lines, sometimes including only its name A use case is a description of sequences of actions that a system performs that yield observable results of value to a particular actor. A use case is used to structure the behavioral things in a model. A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name. Use case An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. An active class is just like a class except that its objects represent elements whose behavior is concurrent with other elements. Graphically, an active class is rendered as a class with double lines on the left and right; it usually includes its name, attributes, and operations Active Class A component is a modular part of the system design that hides its implementation behind a set of external interfaces. Within a system, components sharing the same interfaces can be substituted while preserving the same logical behavior. The implementation of a component can be expressed by wiring together parts and connectors; the parts can include smaller components. Graphically, a component is rendered like a class with a special icon in the upper right corner Component An artifact is a physical and replaceable part of a system that contains physical information ("bits"). In a system, you'll encounter different kinds of deployment artifacts, such as source code files, executables, and scripts. An artifact typically represents the physical packaging of source or run-time information. Graphically, an artifact is rendered as a rectangle with the keyword «artifact» above the name, Artifact A node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and, often, processing capability. A set of components may reside on a node and may also migrate from node to node. Graphically, a node is rendered as a cube, usually including only its name Node Q5. What are Behavioral things in UML? Behavioral things are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time and space. In all, there are three primary kinds of behavioral things. First, an interaction is a behavior that comprises a set of messages exchanged among a set of objects or roles within a particular context to accomplish a specific purpose. The behavior of a society of objects or of an individual operation may be specified with an interaction. An interaction involves a number of other elements, including messages, actions, and connectors (the connection between objects). Graphically, a message is rendered as a directed line, almost always including the name of its operation Interaction Second, a state machine 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. The behavior of an individual class or a collaboration of classes may be specified with a state machine. A state machine involves a number of other elements, including states, transitions (the flow from state to state), events (things that trigger a transition), and activities (the response to a transition). Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates, if any, State machine Third, an activity is a behavior that specifies the sequence of steps a computational process performs. In an interaction, the focus is on the set of objects that interact. In a state machine, the focus is on the life cycle of one object at a time. In an activity, the focus is on the flows among steps without regard to which object performs each step. A step of an activity is called an action. Graphically, an action is rendered as a rounded rectangle with a name indicating its purpose. States and actions are distinguished by their different contexts. Actions Q6. What are Different relationships in UML? There are four kinds of relationships in the UML: 1. 2. 3. 4. Dependency Association Generalization Realization These relationships are the basic relational building blocks of the UML. You use them to write well-formed models. First, a dependency is a semantic relationship between two model elements in which a change to one element (the independent one) may affect the semantics of the other element (the dependent one). Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally including a label. Dependencies Second, an association is a structural relationship among classes that describes a set of links, a link being a connection among objects that are instances of the classes. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts. Graphically, an association is rendered as a solid line, possibly directed, occasionally including a label, and often containing other adornments, such as multiplicity and end names.. Associations Third, a generalization is a specialization/generalization relationship in which the specialized element (the child) builds on the specification of the generalized element (the parent). The child shares the structure and the behavior of the parent. Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent. Generalizations Fourth, a realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out. You'll encounter realization relationships in two places: between interfaces and the classes or components that realize them, and between use cases and the collaborations that realize them. Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship.. Realizations Q7. What are different diagrams in UML? A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and paths (relationships). You draw diagrams to visualize a system from different perspectives, so a diagram is a projection into a system. For all but the most trivial systems, a diagram represents an elided view of the elements that make up a system. The same element may appear in all diagrams, only a few diagrams (the most common case), or in no diagrams at all (a very rare case). In theory, a diagram may contain any combination of things and relationships. In practice, however, a small number of common combinations arise, which are consistent with the five most useful views that comprise the architecture of a software-intensive system. For this reason, the UML includes thirteen kinds of diagrams: 1. 2. 3. 4. 5. 6. Class diagram Object diagram Component diagram Composite structure diagram Use case diagram Sequence diagram 7. Communication diagram 8. State diagram 9. Activity diagram 10. Deployment diagram 11. Package diagram 12. Timing diagram 13. Interaction overview diagram A class diagram shows a set of classes, interfaces, and collaborations and their relationships. These diagrams are the most common diagram found in modeling object-oriented systems. Class diagrams address the static design view of a system. Class diagrams that include active classes address the static process view of a system. Component diagrams are variants of class diagrams. An object diagram shows a set of objects and their relationships. Object diagrams represent static snapshots of instances of the things found in class diagrams. These diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases. component diagram is shows an encapsulated class and its interfaces, ports, and internal structure consisting of nested components and connectors. Component diagrams address the static design implementation view of a system. They are important for building large systems from smaller parts. (UML distinguishes a composite structure diagram, applicable to any class, from a component diagram, but we combine the discussion because the distinction between a component and a structured class is unnecessarily subtle.) A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships. Use case diagrams address the static use case view of a system. These diagrams are especially important in organizing and modeling the behaviors of a system. Both sequence diagrams and communication diagrams are kinds of interaction diagrams. An interaction diagram shows an interaction, consisting of a set of objects or roles, including the messages that may be dispatched among them. Interaction diagrams address the dynamic view of a system. A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages; a communication diagram is an interaction diagram that emphasizes the structural organization of the objects or roles that send and receive messages. Sequence diagrams and communication diagrams represent similar basic concepts, but each diagram emphasizes a different view of the concepts. Sequence diagrams emphasize temporal ordering, and communication diagrams emphasize the data structure through which messages flow. A timing diagram (not covered in this book) shows the actual times at which messages are exchanged. A state diagram shows a state machine, consisting of states, transitions, events, and activities. A state diagrams shows the dynamic view of an object. They are especially important in modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems An activity diagram shows the structure of a process or other computation as the flow of control and data from step to step within the computation. Activity diagrams address the dynamic view of a system. They are especially important in modeling the function of a system and emphasize the flow of control among objects. A deployment diagram shows the configuration of run-time processing nodes and the components that live on them. Deployment diagrams address the static deployment view of architecture. A node typically hosts one or more artifacts. Q8. What are the various development processes? Analysis Process o o Creates conceptual picture Output are requirement model and Analysis model Requirement Model o o o Done by use cases in the use case model Form the basis of construction and testing process Forms the basis of analysis Model Requirement model Consist of o o o A use case model Interface description Problem domain model Analysis Model o o o o o o o Basis of system structure Specify all the logical objects to be included in the system and how these are related and grouped Provide input for the construction process Development of actual system starts with analysis model Focus on the logical structure Define the stable, robust and maintainable structure that is also extensible Creating analysis model corresponding to assigning functionality of use cases to objects Objects in analysis model. Entity object Information about an entity object is stored even after a use case is completed. Control object A control object illustrates functionality that is not contained in any other object in the system Interface object Interface objects interact directly with the environment Dimensions of analysis model Construction Process o o Develops design model and implementation model Includes the implementation and results in complete system Design Model o o o o o Each object will be fully specified Consider the implementation constraints More closer to the the Actual source code Use block term in place of object Stimuli is sent from one block to another to trigger an execution Dimensions of Design model Implementation model o o Consist of annotated source code Object oriented programming language is desirable since all fundamentals concepts can easily be mapped onto language constructs Testing Process Integrates the system, verifies it and decides whether it should be delivered. Q9 What is centralized(Fork) and decentralized(Stair) structure for interaction diagram? Which is better? Fork: Much of the dynamic behavior is placed in a single object, ususally the control object. It knows all the other objects and often uses them for direct questions and commands. Stair: The dynamic behavior is distributed. Each object delegates some responsibility to other objects. Each object knows only a few of the other objects and knows which objects can hepl with a specific behavior. Object-oriented fans claim that the stair structure is better the more the responsibility is spread out, the better. However, this is not always true. In decentralized control structure the operations have a strong connection. The operations will always be performed in the same order Centralized control structure (better support of change) The operations can change order New operations can be inserted as a result of new requirements Fork: Much of the dynamic behavior is placed in a single object, ususally the control object. It knows all the other objects and often uses them for direct questions and commands. Stair: The dynamic behavior is distributed. Each object delegates some responsibility to other objects. Each object knows only a few of the other objects and knows which objects can help with a specific behavior.