SKP Engineering College

Transcription

1 SKP Engineering College Tiruvannamalai A Course Material on Object Oriented Analysis and Design By G.Nanda Kumar Assistant Professor Computer Science and Engineering Department Computer Science Engineering Department 1 Object Oriented Analysis and Design

2 Quality Certificate This is to Certify that the Electronic Study Material Subject Code: CS6502 Subject Name: Object Oriented Analysis and Design Year/Sem: III/V Being prepared by me and it meets the knowledge requirement of the University curriculum. Signature of the Author Name: G.Nanda Kumar Designation: Assistant Professor This is to certify that the course material being prepared by Mr. G.Nanda Kumar is of the adequate quality. He has referred more than five books and one among them is from abroad author. Signature of HD Name: Seal: Signature of the Principal Name: Dr.V.Subramania Bharathi Seal: Computer Science Engineering Department 2 Object Oriented Analysis and Design

3 CS OBJECT ORIENTED ANALYSIS AND DESIGN L T P C UNIT I- UML DIAGRAMS Introduction to OOAD Unified Process - UML diagrams Use Case Class Diagrams Interaction Diagrams State Diagrams Activity Diagrams Package, component and Deployment Diagrams UNIT II - DESIGN PATTERNS GRASP: Designing objects with responsibilities Creator Information expert Low Coupling High Cohesion Controller - Design Patterns creational - factory method - structural Bridge Adapter - behavioral Strategy observer UNIT III - CASE STUDY Case study the Next Gen POS system, Inception -Use case Modeling - Relating Use cases include, extend and generalization - Elaboration - Domain Models - Finding conceptual classes and description classes Associations Attributes Domain model refinement Finding conceptual class Hierarchies - Aggregation and Composition UNIT IV - APPLYING DESIGN PATTERNS System sequence diagrams - Relationship between sequence diagrams and use cases Logical architecture and UML package diagram Logical architecture refinement - UML class diagrams - UML interaction diagrams - Applying GoF design patterns UNIT V - CODING AND TESTING 9 Mapping design to code Testing: Issues in OO Testing Class Testing OO Integration Testing GUI Testing OO System Testing TOTAL: 45 PERIODS TEXT BOOK: 1. Craig Larman, "Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, Pearson Education, Computer Science Engineering Department 3 Object Oriented Analysis and Design

4 REFERENCES: 1. Simon Bennett, Steve Mc Robb and Ray Farmer, Object Oriented Systems Analysis and Design Using UML, Fourth Edition, Mc-Graw Hill Education, Erich Gamma, and Richard Helm, Ralph Johnson, John Vlissides, Design patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Martin Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third edition, Addison Wesley, Paul C. Jorgensen, Software Testing:- A Craftsman s Approach, Third Edition, Auerbach Publications, Taylor and Francis Group, Computer Science Engineering Department 4 Object Oriented Analysis and Design

5 CONTENTS S.No Particulars Page 1 Unit I 6 2 Unit II 17 3 Unit III 27 4 Unit IV 38 5 Unit V 47 Computer Science Engineering Department 5 Object Oriented Analysis and Design

6 Unit I UML DIAGRAMS Part A 1. What is an object? [co1-l1-nov/dec2014] An object is a combination of data and logic; the representation of some real-world entity. 2. What are the main advantages of object oriented development? [co1-l1- NOV/DEC2014] High level of abstraction Seamless transition among different phases of software development Encouragement of good programming techniques Promotion of reusability 3. What is object oriented system development methodology? [co1-l1- NOV/DEC2014] Object oriented system development methodology is a way to develop software by building self contained modules or objects that can be easily replaced, modified and reused. 4. Distinguish between method and message in object. [co1-l1-nov/dec2014] Method Message Methods are similar to functions, procedures Message essentially are non specific or function subroutines in more traditional programming Calls languages Method is an implementation Message is an instruction An object understands a message when it In an object oriented system, a method is can match the message to a method that has invoked by sending an object a message. the same name as the message. 5. What is analysis and design? [co1-l1-nov/dec2014] Analysis emphasizes an investigation of the problem and requirements, rather than a solution.for example, if a new computerized library information system is desired, how it will be used. Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation.for example, a description of a database schema and software objects. 6. What is object oriented analysis and design? [co1-l1-nov/dec2014] Computer Science Engineering Department 6 Object Oriented Analysis and Design

7 During object oriented analysis,there is an emphasis on finding and describing the objects or concepts in the problem domain.forexample,in the case of the library information system,some of the concepts include book,library and patron. During object oriented design,there is an emphasis on defining software objects and how they collaborate to fulfill the requirements.forexample,in the library system,a book software object may have a title attribute and a get chap-ter method 7. What is UML? [co1-l1-nov/dec2014] Unified modeling language is a set of notations and conventions and diagrams to describe and model an application. 8. What are the primary goals in the design of UML? [co1-l1-nov/dec2014] ß Provide users a ready to use expressive visual modeling language so they can develop and exchange meaningful models. ß Provide extensibility and specialization mechanism to extend the core concepts. ß Encourage the growth of oo tools market. ß Support higher level development concepts. 8. Define class diagram. [co1-l1-nov/dec2014] The main static structure analysis diagram for the system,it represents the class structure of a system including the relationships between class and inheritance structure. 9. Define activity diagram. [co1-l1-nov/dec2016] A variation or special case of a state machine in which the states are activities representing the performance of operations and the transitions are triggered by the completion of the operations. 10. What is interaction diagram? Mention its types. [co1-l1-may/jun2008] Intraction diagrams are diagrams that describe how groups of objects collaborate to get the job done interaction diagrams capture the behavior of the single use case, showing the pattern of interaction among objects. Types: Sequence diagram Collaboration diagram 11. What is sequence diagram? [co1-l1-nov/dec2014] It is an easy and intuitive way of describing the behavior of a system by viewing the interaction between the system and its environment. 12. What is collaboration diagram? [co1-l1-nov/dec2014] It represents a collaboration, which is a set of objects related in a particular context, and interaction, which is a set of messages exchanged among the objects with in collaboration to achieve a desired outcome. 13. Define start chart diagram? [co1-l1-nov/dec2016] It shows a sequence of states that an object goes through during its life in response to Computer Science Engineering Department 7 Object Oriented Analysis and Design

8 events.a state is represented as a round box, which may contain one or more compartments.the compartments are all optional. 14. What is meant by implementation diagram? [co1-l1-nov/dec2016] Implementation diagrams show the implementation phase of systems development such as the source code structure and the run time implementation structure. There are two types of implementation diagrams: Component diagram and Development diagram 16. Define component diagram. [co1-l1-nov/dec2014] A component diagram shows the organization and dependencies among a set of components. A component diagram is used to model the static implementation view of a system. This involves modeling the physical thing that reside on a mode, such as executable, libraries, files and documents. 17. Define deployment diagram. [co1-l1-nov/dec2016] Deployment diagram shows the configuration of run time processing elements and the software components, processes and objects that live in them. Deployment diagrams are used to model the static deployment view of a system. A deployment diagram is a graph of nodes connected by communication association. 18. What is UP? [co1-l1-nov/dec2014] A software development process describes an approach to building, deploying and possibly maintaining software. The unified process has emerged as a popular iterative software development process for building object oriented system. 19. What is iteration? [co1-l1-nov/dec2014] A key practice in both the UP and most other modern methods is iterative development. In this lifecycle approach, development is organized into a series of short, fixed lengthmini projects called iterations. 20. What is iterative evolutionary development? [co1-l1-nov/dec2014] The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system. The system grows incrementally over time, iteration by iteration and thus this approach is also known as iterative and incremental development. 21. What are the phases of unified process? [co1-l1-nov/dec2014] ß Inception ß Elaboration ß Construction ß Transition 22. What is inception? [co1-l1-nov/dec2014] Inception is the initial short step to establish a common vision and basic scope for the Computer Science Engineering Department 8 Object Oriented Analysis and Design

9 project. It will include analysis of perhaps 10% of the use cases, analysis of the critical non-functional requirement, creation of a business case and preparation of the development environment. 23. Define use case modeling. [co1-l1-nov/dec2014] Use case modeling is a form of requirement engineering. How to create an SRS in what we might call the traditional way. Use case modeling is a different and complementary way of eliciting and documenting requirements. 24. Define use case generalization? [co1-l1-nov/dec2014] Use case generalization is used when you have one or more use cases that are rally specializations of more general case. 25. What is UML activity diagram? [co1-l1-nov/dec2014] A UML activity diagram shows sequential and parallel activities in a process, they are useful for modeling business processes, workflows, data flows and complex algorithms. PART-B 1. Explain about Object Oriented Analysis and Design process. [CO1-L2- NOV/DEC 2016] The Unified Modeling Language is commonly used to visualize and construct systems which are software intensive. Because software has become much more complex in recent years, developers are finding it more challenging to build complex applications within short time periods. Even when they do, these software applications re often filled with bugs, and it can take programmers weeks to find and fix them. This s time that has been wasted, since an approach could have been used which would have educed the number of bugs before the application was completed. Three ways to apply UML: 1. UML as sketch: Informal and incomplete diagrams Created to explore difficult parts of the problem. 2. UML as blueprint: Detailed design diagram Used for better understanding of code 3. UML as programming language: Complete executable specification of a software system in UML Three perspectives to apply UML: Conceptual perspective: Diagrams describe the things of real world. UML diagrams are used to describe things in situations of real world. Raw UML object diagram notation used to visualize. Computer Science Engineering Department 9 Object Oriented Analysis and Design

10 Specification perspective: Diagrams describe software abstractions or components with specifications and interfaces. It describes the real world things, software abstraction and component with specification and interfaces. Raw UML class diagram notation used to visualize software components. Implementation perspective:diagrams describe software implementation in a particular technology PHASES OF UP: The Unified Process has emerged as a popular iterative software development process for building object oriented systems. software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP). I.Inception: Inception is the initial stage of project. It deals with approximate vision, business case, scope of project and vague estimation. Initial stage of project Approximate vision Business Case and scope Vague estimate Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception Phase is long then it may be an indication of excessive up-front specification, which is contrary to the spirit of the Unified Process. The following are typical goals for the Inception phase. 1. Establish a justification or business case for the project Establish the project scope and boundary conditions 2. Outline the use cases and key requirements that will drive the design tradeoffs 3. Outline one or more candidate architectures 4. Identify risks 5. Prepare a preliminary project schedule and cost estimate The Lifecycle Objective Milestone marks the end of the Inception phase. Advantages of inception. Estimation or plans are expected to be reliable. After inception, design architecture can be made easily becauseall the use cases are written in detail. Computer Science Engineering Department 10 Object Oriented Analysis and Design

11 2. Discuss about unified process. [CO1-L1-NOV/DEC 2014] During the Elaboration phase the project team is expected to capture a healthy majority of the system requirements. However, the primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture. Common processes undertaken in this phase include the creation of use case diagrams, conceptual diagrams (class diagrams with only 1. Construction: ` Construction is the largest phase in the project. In this phase the remainder of the system is built on the foundation laid in Elaboration. System features are implemented in a series of short, timeboxed iterations. Each iteration results in an executable release of the software. It is customary to write full text use cases during the construction phase and each one becomes the 3. start of a new iteration. Common UML (Unified Modelling Language) diagrams used during this phase include Activity, Sequence, Collaboration, State (Transition) and Interaction Overview diagrams. The Initial Operational Capability Milestone marks the end of the Constructionphase. Design the elements Preparation for deployment. Transition: The final project phase is Transition. In this phase the system is deployed to the target users. Feedback received from an initial release (or initial releases) may result in further refinements to be incorporated over the course of several Transition phase iterations. The Transition phase also includes system conversions and user training. The Product Release Milestone marks the end of the Transition phase. Beta tests Deployments NEXT POS SYSTEM: The case study is the NextGen point-of-sale (POS) system. In this apparently straightforwardproblem domain, we shall see that there are very interesting requirement and design problems to solve. In addition, it is a realistic problem; organizations really do write POS systems using object technologies. A POS system is a computerized application used (in part) to record sales and handle payments; it is typically used in a retail store. It includes hardware components such as a computer and bar code scanner, and software to run the system. It interfaces to various service applications, such as a third-party tax calculator and inventory control. These systems must be relatively fault-tolerant; that is, even if remote services are temporarily unavailable (such as the inventory system), they must still be capable of capturing sales and handling at least cash payments (so that the business is not crippled). A POS system increasingly must support multiple and varied client-side terminals and interfaces. These include a thin-client Web browser terminal, a regular personal computer with. Computer Science Engineering Department 11 Object Oriented Analysis and Design

12 3. Explain use case modeling with example.co1-l2-nov/dec 2016] The Use Case Model describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example login to system, register with system and create order are all Use Cases. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behavior. Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work. Actors An Actor is a user of the system. This includes both human users and other computer systems. An Actor uses a Use Case to perform some piece of work which is of value to the business. The set of Use Cases an actor has access to defines their overall role in the system and the scope of their action. Constraints, Requirements and Scenarios The formal specification of a Use Case includes: 1. Requirements: These are the formal functional requirements that a Use Case must provide to the end user. They correspond to the functional specifications found in structured methodologies. A requirement is a contract that the Use Case will perform some action or provide some value to the system. 2. Constraints: These are the formal rules and limitations that a Use Case operates under, and includes pre-post- and invariant conditions. A pre-condition specifies what must have already occurred or be in place before the Use Case may start. A post-condition documents what will be true once the Use Case is complete. An invariant specifies what will be true throughout the time the Use Case operates. 3.Scenarios: Scenarios are formal descriptions of the flow of events that occurs during a Use Case instance. These are usually described in text and correspond to a textual representation of the Sequence Diagram. USE CASE RELATIONSHIPS. Use case relationships is Divided into three types 1. Include relationship 2. Extend relationship 3. Generalization 1. Include relationship: It is common to have some practical behavior that is common across severa use cases. Computer Science Engineering Department 12 Object Oriented Analysis and Design

13 It is simply to underline it or highlight it in some fashion Example: paying by credit: Include Handle Credit Payment 2. Extend relationship: Extending the use case or adding new use case to the process Extending use case is triggered by some conditions called extension point. 3. Generalization: Complicated work and unproductive time is spending in this use case relationship. Use case experts are successfully doing use case work without this relationship. Includes and Extends relationships between Use Cases One Use Case may include the functionality of another as part of its normal processing. Generally, it is assumed that the included Use Case will be called every time the basic path is run. An example may be to list a set of customer orders to choose from before modifying a selected order in this case the <list orders> Use Case may be ncluded every time the <modify order> Use Case is run. A Use Case may be included by one or more Use Cases, so it helps to reduce duplication of functionality by factoring out common behavior into Use Cases that are re-used many times. One Use Case may extend the behavior of another - typically when exceptional circumstances are encountered. Relationships Between Use Cases Use cases could be organized using following relationships: Generalization Association Extend Include 4.Explain about interaction diagrams with example. [CO1-L2-NOV/DEC2014] Interaction Overview Diagram is one of the thirteen types of diagrams of the Unified Modeling Language (UML), which can picture a control flow with nodes that can contain interaction diagrams. The interaction overview diagram is similar to the activity diagram, in that both visualize a sequence of activities. The difference is that, for an interaction overview, each individual activity is pictured as a frame which can contain a nested interaction diagrams. This makes the interaction overview diagram useful to "deconstruct a complex scenario that would otherwise require multiple if-then-else paths to be illustrated as a single sequence diagram". The other notation elements for interaction overview diagrams are the same as for activity diagrams. These include initial, final, decision, merge, fork and join nodes. The two new elements in the interaction overview diagrams are the "interaction occurrences" and "interaction elements." Computer Science Engineering Department 13 Object Oriented Analysis and Design

14 STATE DIAGRAMS: The state diagram in the Unified Modeling Language is essentially a Harel statechart with standardized notation which can describe many systems, from computer programs to business processes. In UML 2, the name has been changed to State Machine Diagram. The following are the basic notational elements that can be used to make up a diagram: Filled circle, representing to the initial statehollow circle containing a smaller filled circle, indicating the final state (if any)rounded rectangle, denoting a state. Top of the rectangle contains a name of the state. Can contain a horizontal line in the middle, below which the activities that are done in that state are indicatedarrow, denoting transition. The name of the event (if any) causing this transition labels the arrow body. A guard expression may be added before a "/" and enclosed in square-brackets ( eventname[guardexpression] ), denoting that this expression must be true for the transition to take place. If an action is performed during this transition, it is added to the label following a "/" ( eventname[guardexpression]/action ). Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line entering and x>1 lines leaving. These denote join/fork, respectively. Computer Science Engineering Department 14 Object Oriented Analysis and Design

15 5. Explain UML activity diagram with example.[co1-l2-nov/dec2016] ACTIVITY DIAGRAMS includes 1. Class diagram 2. Component diagram 3. Composite structure diagram 4. Deployment diagram 5. Object diagram 6. Package diagram 7. Profile diagram Behavioral UML diagrams 1. Activity diagram 2. Communication diagram 3. Interaction overview diagram 4. Sequence diagram 5. State diagram 6. Timing diagram 7. Use case diagram Computer Science Engineering Department 15 Object Oriented Analysis and Design

16 Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organisational processes (i.e. workflows). Activity diagrams show the overall flow of control. Activity diagrams are constructed from a limited number of shapes, connected with arrows. The most important shape types: rounded rectangles Represent actions; diamonds represent decisions;bars represent the start (split) or end (join) of oncurrentactivities; a black circle represents the start (initial state) of the workflow; an encircled black circle represents the end (final state). Arrows run from the start towards the end and represent the order in which activities happen. Activity diagrams may be regarded as a form of flowchart. Typical flowchart techniques lack constructs for expressing concurrency[citation needed. However, the join and split symbols in activity diagrams only resolve this for simple cases; the meaning of the model is not clear when they are arbitrarily combined with decisions or loops. UML activity diagrams in version 2.x can be used in various domains, i.e. in design of embedded systems. It is possible to verify such a specification using model checking technique. Computer Science Engineering Department 16 Object Oriented Analysis and Design

17 Unit II Design Patterns Part-A 1. How to Choose the Initial Domain Object? [CO2-L1-MAY/JUN2008] Choose as an initial domain object a class at or near the root of the containment or aggregation hierarchy of domain objects. This may be a facade controller, such as Register, or some other object considered to contain all or most other objects, such as a Store. 2. Define patterns. [CO2-L1-NOV/DEC2016] A pattern is a named problem/solution pair that can be applied in new context, with advice on how to apply it in novel situations and discussion of its trade-offs. 3. How to Connect the UI Layer to the Domain Layer?[CO2-L1-NOV/DEC2014] An initializing routine (for example, a Java main method) creates both a UI and a domain object, and passes the domain object to the UI. A UI object retrieves the domain object from a well-known source, such as a factory object that is responsible for creating domain objects. 4. Mention the Interface and Domain Layer Responsibilities. [CO2-L2- NOV/DEC2014] The UI layer should not have any domain logic responsibilities. It should only be responsible for user interface tasks, such as updating widgets. The UI layer should forward requests for all domain-oriented tasks on to the domain layer, which is responsible for handling them. 5. How to Apply the GRASP Patterns? [CO2-L1-NOV/DEC2016] The following sections present the first five GRASP patterns: Information Expert Creator High Cohesion Low Coupling Controller 6. Define Responsibilities and Methods.[CO2-L1-NOV/DEC 2014] The UML defines a responsibility as "a contract or obligation of a classifier" [OMG01]. Responsibilities are related to the obligations of an object in terms of its behavior. Basically, these responsibilities are of the following two types: Computer Science Engineering Department 17 Object Oriented Analysis and Design

18 7. List out some scenarios that illustrate varying degrees of functional cohesion.[co2-l1-nov/dec2016] Very low cohesion Low cohesion High cohesion Moderate cohesion 8.Define Modular Design.[CO2-L1-MAY/JUN2008] Coupling and cohesion are old principles in software design; designing with objects does not imply ignoring well-established fundamentals. Another of these, which is strongly related to coupling and cohesion is to promote modular design. 9. What is meant by Abstract Class Abstract Factory?[CO2-L1-NOV/DEC2016] A common variation on Abstract Factory is to create an abstract class factory that is accessed using the Singleton pattern, reads from a system property to decide which of its subclass factories to create, and then returns the appropriate subclass instance. This is used, for example, in the Java libraries with the java.awt.toolkit class, which is an abstract class abstract factory for creating families of GUI widgets for different operating system and GUI subsystems. 10. Differentiate coupling and cohesion.[co1-l1-nov/dec2014] Coupling deals with interactions between objects or software components while cohesion deals with theinteractions within a single object or software component. Highly cohesive components can lower coupling because only a minimum of essential format in need to passed between components. 11. What is meant by Fine-Grained Classes? [CO2`-L1-NOV/DEC2014] Consider the creation of the Credit Card, Drivers License, and Check software objects. Our first impulse might be to record the data they hold simply in their related payment classes, and eliminate such fine-grained classes. However, it is usually a more profitable strategy to use them; they often end up providing useful behavior and being reusable. For example, the Credit Card is a natural Expert on telling you its credit company type (Visa, MasterCard, and so on). This behavior will turn out to be necessary for our application. 12. Define coupling. [CO2-L1-NOV/DEC2016] The degree to which components depend on one another. There are two types of coupling, "tight" and "loose". Loose coupling is desirable for good software engineering but tight coupling may be necessary for maximum performance. Coupling is increased when the data exchanged between components becomes larger or more complex. 13. What do you mean by degree of coupling? [CO2-L1-NOV/DEC2016] The degree of coupling is a function of How complicated the connection is Whether the Computer Science Engineering Department 18 Object Oriented Analysis and Design

19 connection refers to the object itself or something inside it. What is being The degree or strength of coupling between two components is measured by the mount and complexity of information transmitted between them. Coupling increases hincreasing complexity and decreases when the connection is to the component interface rather than to an internal component. Coupling is also lower for data connections than for control connections. 14. What do you mean by cohesion? Give the types of cohesion. [CO2-L1- NOV/DEC2016] Cohesion can be defined as the interactions within a single object or software component. Cohesion reflects the single purposeness of an object. Cohesion helps in designing classes that have very specific goals and clearly defined purposes. Method cohesion Class cohesion Inheritance cohesion 16. What do you mean by design patterns? [CO2-L1-NOV/DEC2016] Design patterns are devices that allow systems to share knowledge about their design, by describing commonly recurring structures of communicating components that solve a general design problem within a particular context. A design pattern provides a scheme for refining the subsystems or components of a software system or the relationships among them. Design patterns are documented by writing essays in a fairly well-defined form. 17. What are the three basic types of attributes? [CO2-L1-NOV/DEC2016] The three basic types of attributes are Single-value attributes. The single -valued attribute has only one value or state. Multiplicity or multi value attributes. The multiplicity or multi valued attribute can have a collection of many values at any point in time. Reference to another object, or instance connection. These attributes are required to provide the mapping needed by an object to fulfill its responsibilities, in other words, instance connection model association. 18. What is a Metaphor? [CO2-L1-NOV/DEC2014] It is an analogy that relates two unrelated things by using one to denote the other. 19. Give the three UI design rules. [CO2-L1-NOV/DEC2014] UI design rule 1: Making the interface simple. UI design rule 2: Making the interface transparent and natural. UI design rule. 3: Allowing users to be in control of the software. 20. Define Package. [CO2-L1-NOV/DEC2016] A package groups and manages the modeling elements, such as classes, their associations, and their structures. Packages themselves may be nested within other packages. A package may contain both other packages and ordinary model elements. The entire system description can be thought of as a single high-level sub-system package with everything else init. All kinds of UML model elements and diagrams can be organized into packages. Computer Science Engineering Department 19 Object Oriented Analysis and Design

20 21. What is concurrency policy? A concurrency control policy dictates what happens when conflicts arise between transactions that attempt access to the same object and how these conflicts are to be resolved There are two policies: 1. Conservative or pessimistic policy Allows a user to lock all objects or records when they are accessed and to release the locks only after a transaction commits. 2. Optimistic policy Two conflicting transactions are compared in their entirety and then their serial ordering is determined. PART-B 1. Explain GRASP: designing objects with responsibilities. [CO2-L2- NOV/DEC2016] GRASP: Designing objects with responsibilities: General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design. The different patterns and principles used in GRASP are: Controller, Creator, Indirection, Information Expert, High Cohesion, Low Coupling, Polymorphism, Protected Variations, and Pure Fabrication. All these patterns answer some software problem, and in almost every case these problems are common to almost every software development project. These techniques have not been invented to create new ways of working, but to better document and standardize old, tried-and-tested programming principles in objectoriented design. Computer scientist Craig Larman states that "the critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology."[1] Thus, GRASP is really a mental toolset, a learning aid to help in the design of object-oriented software. CONTROLLER: The Controller pattern assigns the responsibility of dealing with system events to a non-ui class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a system event. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have a single UserController, instead of two separate Computer Science Engineering Department 20 Object Oriented Analysis and Design

21 use case controllers). It is defined as the first object beyond the UI layer that receives and coordinates ("controls") a system operation. The controller should delegate the work that needs to be done to other objects; it coordinates or controls the activity. It should not do much work itself. The GRASP Controller can be thought of as being a part of the Application/Service layer (assuming that the application has made an explicit distinction between the application/service layer and the domain layer) in an object-oriented system with Common layers in an information system logical architecture. CREATOR:creational factory method Creation of objects is one of the most common activities in an object-oriented system. Which class is responsible for creating objects is a fundamental property of the relationship between objects of particular classes. In general, a class B should be responsible for creating instances of class A if one, or preferably more, of the following apply: Instances of B contain or compositely aggregate instances of A Instances ApplicationsFactory objects are common in toolkits and frameworks where library code needs to create objects of types which may be subclassed by applications using the framework. They are also used in test-driven development to allow classes to be put under test 2. Explain GoF design patterns.[co2-l2-nov/dec2016] High Cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of Low Coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and averse to change. The Indirection pattern supports low coupling (and reuse potential) between two elements by assigning the responsibility of mediation between them to an intermediate object. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern. Information Expert Information Expert (also Expert or the Expert Principle) is a principle used to determine where to delegate responsibilities. These responsibilities include methods, computed fields, and so on. Using the principle of Information Expert, a general approach to assigning responsibilities is to look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored. Information Expert will lead to placing the responsibility on the class with the most information required to fulfill it.low Coupling. Computer Science Engineering Department 21 Object Oriented Analysis and Design

22 Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support:lower dependency between the classes,change in one class having lower impact on other classes, higher reuse potential. Polymorphism According to Polymorphism, responsibility of defining the variation of behaviors based on type is assigned to the types for which this variation happens. This is achieved using polymorphic operations. The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface. A Pure Fabrication is a class that does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion, and the reuse potential thereof derived (when a solution presented by the Information Expert pattern does not). This kind of class is called "Service" in Domain-driven design. 3. Discuss about creator and information expert.[co2-l1-nov/def2014] Information Expert Name:Information Expert Problem:What is a general principle of assigning responsibility to objects? Solution: Assign a responsibility to the class that has the information needed to fulfill it Example In the NextGen application, some class needs to know the Gand total of a sale Discussion Information Expert is frequently used in the assignment of responsibilities; it is a basic guiding principles used continuously in object design. The fulfillment of a responsibility often requires information spread across different classes of objects. Expert usually leads to designs where a software object does those operations that are normally done to the inanimate real -world thing it represents. The Information Expert pattern like many things in OO has a real world analogy Contraindications There are situations where a solution suggested by Expert is undesirable, usually because of problems in coupling and cohesion Ex. who should be responsible for saving a Sale in a database? 4. Explain about low coupling and high cohesion. [CO2-L1-NOV/DEC2014] LOW COUPLING: Name : Low Coupling Problem : How to support low dependency, low change impact, and increased reuse? Solution : Assign a responsibility so that coupling remains low Example Computer Science Engineering Department 22 Object Oriented Analysis and Design

23 Assume a need to create a Payment instance and associate it with the Sale, who should be responsible for this? Discussion: Low Coupling is a principle to keep in mind during all design decisions; it is an underlying goal to continually consider. Although, in general, a low coupling is preferred, it shouldn t be taken to excess. Some moderate degree of coupling between classes is normal and necessary to create an OO system in which tasks are fulfilled by a collaboration between connected objects Contradictions High coupling to stable elements and to pervasive elements is seldom a problem. Ex. a Java application can safely couple itself to the Java libraries (java.util, and so on) because they are stable and widespread Benefits not affected by changes in other components simple to understand in isolation convenient to reuse choices: Represents the overall system, a device, or a subsystem (façade controller) Represents a use case scenario (use case controller) Controller is a non- user interface object responsible for receiving or handling a system event. A controller defines the method for the system operations System ` Systems receive externally input events, typically involving a GUI operated by a person. ` In all cases, some handler for these events must be chosen The Controller pattern provides guidance for generally accepted, suitable choices ` Normally, a controller should delegate to other objects the work that needs to be done; it coordinates or controls the activity. It doesn t do much work itself. SIGNIFICANCE: Increased potential for reuse and pluggable interfaces. Opportunity to reason about the state of the use case Implementation Implementation Java Swing: Rich Client UI Implementation with Java Struts: Client Browser and Web UI Issues and Solutions: Bloated Controllers Poorly designed, a controller will have low cohesion unfocused and handling too many areas of responsibility Signs of bloating 5. Explain about factory and observer patterns. [CO2-L2-NOV/DEC2016] STRUCTURAL BRIDGE: The bridge pattern is a design pattern used in software engineering which is meant to "decouple an abstraction from its implementation so that the two can vary independently".[1] The bridge uses encapsulation, aggregation, and can use Computer Science Engineering Department 23 Object Oriented Analysis and Design

24 inheritance to separate responsibilities into different classes. When a class varies often, the features of object-oriented programming become very useful because changes to a program's code can be made easily with minimal prior knowledge about the program. The bridge pattern is useful when both the class and what it does vary often. The class itself can be thought of as the implementation and what the class can do as the abstraction. The bridge pattern can also be thought of as two layers of abstraction. When there is only one fixed implementation, this pattern is known as the Pimpl idiom in the C++ world. The bridge pattern is often confused with the adapter pattern. In fact, the bridge pattern is often implemented using the class adapter pattern, e.g. in the Java code below. Variant: The implementation can be decoupled even more by deferring the presence of the implementation to the point where the abstraction is utilized. 6. Explain adapter and singleton with an example. [CO2-L2-NOV/DEC2016] ADAPTER and STRUCTURE: IConvert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. Wrap an existing class with a new interface. Impedance match an old component to a new systemproblem.an "off the shelf" component offers compelling functionality that you would like to reuse, but its "view of the world" is not compatible with the philosophy and architecture of the system currently being developed. Structure Category: wrapper Similar patterns: Facade Proxy Discussion: Reuse has always been painful and elusive. One reason has been the tribulation of designing something new, while reusing something old. There is always something not quite right between the old and the new. It may be physical dimensions or Computer Science Engineering Department 24 Object Oriented Analysis and Design

25 misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards. It is very similar to the electrical engineering activity of "impedance matching" adapting the input resistance, inductance, and capacitance of a load to match the output impedance of a source. STRUCTURE: Below, a legacy Rectangle component's display() method expects to receive "x, y, w, h" parameters. But the client wants to pass "upper left x and y" and "lower right x and y". This incongruity can be reconciled by adding an additional level of indirection i.e. an Adapter object. BEHAVIORAL STRATEGY: A generic value of the software community for years has been, "maximize cohesion and minimize coupling". The object-oriented design approach shown in Figure 21-1 is all about minimizing coupling. Since the client is coupled only to an abstraction (i.e. a useful fiction), and not a particular realization of that abstraction, the client could be said to be practicing "abstract coupling". an object-oriented variant of the more generic exhortation "minimize coupling". A more popular characterization of this "abstract coupling" principle is... Program to an interface, not an implementation. Clients should prefer the "additional level of indirection" that an interface (or an abstract base class) affords. The interface captures the abstraction (i.e. the "useful fiction") the client wants to exercise, and the implementations of that interface are effectively hidden. The Strategy design pattern discusses and documents the leverage represented in FigureOther terms that are part and parcel of this same concept are: polymorphism, and dynamic binding. Example:"A Strategy defines a set of algorithms that can be used interchangeably. Modes of transportation to an airport is an example of a Strategy. Several options exist such as driving one's own car, taking a taxi, an airport shuttle, a city bus, or a limousine service. For some airports, subways and helicopters are also available as a mode of transportation to the airport. Any of these modes of transportation will get a traveler to the airport, and they can be used interchangeably. The traveler must chose the Strategy based on tradeoffs between cost, convenience, and time." Computer Science Engineering Department 25 Object Oriented Analysis and Design

26 OBSERVER: Discussion: Define an object that is the "keeper" of the data model and/or business logic (the Subject). Delegate all "view" functionality to decoupled and distinct Observer objects. Observers register themselves with the Subject as they are created. Whenever the Subject changes, it broadcasts to all registered Observers that it has changed, and each Observer queries the Subject for that subset of the Subject's state that it is responsible for monitoring. This allows the number and "type" of "view" objects to be configured dynamically, instead of being statically specified at compile-time. The protocol described above specifies a "pull" interaction model. Instead of the Subject pushing" what has changed to all Observers, each Observer is responsible for "pulling" its particular "window of interest" from the Subject. The "push" model compromises reuse, while the "pull" model is less efficient. Issues that are discussed, but left to the discretion of the designer, include: implementing event compression (only sending a single change broadcast after a series of consecutive changes has occurred), having a single Observer monitoring multiple Subjects, and ensuring that a Subject notify its Observers when it is about to go away. The Observer pattern captures the lion's share of the Model-View-Controller architecture that has been a part of the Smalltalk community for years. Computer Science Engineering Department 26 Object Oriented Analysis and Design

27 Unit III Case Study Part-A 1. What is Inception? [CO3-L1-NOV/DEC2016] Inception is the initial short step to establish a common vision and basic scope for the Project. It will include analysis of perhaps 10% of the use cases, analysis of the critical non- Functional requirement, creation of a business case, and preparation of the development environment so that programming can start in the elaboration phase. Inception in one Sentence: Envision the product scope, vision, and business case. 2. What Artifacts May Start in Inception? [CO3-L1-NOV/DEC2014] Some sample artifacts are Vision and Business Case, Use-Case Model, Supplementary Specification, Glossary, Risk List & Risk Management Plan, Prototypes and proof-of-concepts etc. 3. Define Requirements and mention its types. [CO3-L1-NOV/DEC2016] Requirements are capabilities and conditions to which the system and more broadly, the project must conform. a. Functional b. Reliability c. Performance d. Supportability 4. What are Actors? [CO3-L1-NOV/DEC2016] An actor is something with behavior, such as a person (identified by role), computer system, or organization; for example, a cashier. 5. What is a scenario? [CO3-L1-NOV/DEC2016] A scenario is a specific sequence of actions and interactions between actors and the system; it is also called a use case instance. It is one particular story of using a system, or one path through the use case; for example, the scenario of successfully purchasing items with cash, or the scenario of failing to purchase items because of a credit payment denial. 6. Define Use case. [CO3-L1-NOV/DEC2016] A use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal. Use cases are text documents, not diagrams, and use-case modeling is primarily an act of writing text, not drawing diagrams. 7. What are Three Kinds of Actors? [CO3-L1-NOV/DEC2016] Primary actor, Supporting actor, offstage actor. 8. What Tests Can Help Find Useful Use Cases? [CO3-L1-NOV/DEC2016] Computer Science Engineering Department 27 Object Oriented Analysis and Design

28 a. The Boss Test b. The EBP Test c. The Size Test 9. What are Use Case Diagrams? [CO3-L1-NOV/DEC2016] A use case diagram is an excellent picture of the system context; it makes a good context diagram that is, showing the boundary of a system, what lies outside of it, and how it gets used. It serves as a communication tool that summarizes the behavior of a system and its actors. 10. What are Activity Diagrams? [CO3-L1-NOV/DEC2016] A diagram which is useful to visualize workflows and business processes. These can be a useful alternative or adjunct to writing the use case text, especially for business use cases that describe complex workflows involving many parties and concurrent actions. 11. What is Elaboration? [CO3-L1-NOV/DEC2016] Elaboration is the initial series of iterations during which the team does serious investigation, implements (programs and tests) the core architecture, clarifies most requirements, and tackles the high-risk issues. In the UP, "risk" includes business value. Therefore, early work may include implementing scenarios that are deemed important, but are not especially technically risky. 12. What are the tasks performed in elaboration? [CO3-L1-NOV/DEC2016] The core, risky software architecture is programmed and tested The majority of requirements are discovered and stabilized The major risks are mitigated or retired. 13. What are the key ideas and best practices that will manifest in elaboration? [CO3-L1-NOV/DEC2016] Do short time boxed risk-driven iterations. Start programming early Adaptively design, implement, and test the core and risky parts of the architecture Test early, often, realistically Adapt based on feedback from tests, users, developers 14. What artifacts may start in elaboration? [CO3-L1-NOV/DEC2014] Domain Model This is a visualization of the domain concepts; it is similar to a static information model of the domain entities. This is the set of diagrams that describes the logical design. Computer Science Engineering Department 28 Object Oriented Analysis and Design

29 Design Model Software Document Data Model Use-Case Storyboards, UI Prototypes This includes software class diagrams, object interaction diagrams, package diagrams, and so forth. A learning aid that summarizes the key architectural issues Architecture and their resolution in the design. It is a summary of the outstanding design ideas and their motivation in the system. This includes the database schemas, and the mapping strategies between object and non-object representations. Descriptions of the user interface, paths of navigation, usability models, and so forth. 15. What are the key ideas for Planning the Next Iteration? [CO3-L1- NOV/DEC2014] Organize requirements and iterations by risk, coverage, and criticality. 16. What is a Domain Model? [CO3-L1-NOV/DEC2016] A domain model is a visual representation of conceptual classes or real-situation objects in a domain. The term "Domain Model" means a representation of real-situation conceptual classes, not of software objects. The term does not mean a set of diagrams describing software classes, the domain layer of a software architecture, or software objects with responsibilities. 17. How the domain model is illustrated? [CO3-L1-NOV/DEC2016] Applying UML notation, a domain model is illustrated with a set of class diagrams in which no operations (method signatures) are defined. It provides a conceptual perspective. It may show: ß domain objects or conceptual classes ß associations between conceptual classes ß attributes of conceptual classes 18. Why Call a Domain Model a "Visual Dictionary"? [CO3-L1-NOV/DEC2016] The information it illustrates could alternatively have been expressed in plain text. But it's easy to understand the terms and especially their relationships in a visual language, Computer Science Engineering Department 29 Object Oriented Analysis and Design

30 since our brains are good at understanding visual elements and line connections. Therefore, the domain model is a visual dictionary of the noteworthy abstractions, domain vocabulary, and information content of the domain. 19. What are the elements not suitable in a domain model? [CO3-L1- NOV/DEC2016] The following elements are not suitable in a domain model ß Software artifacts, such as a window or a database, unless the domain being modeled is of software concepts, such as a model of graphical user interfaces. ß Responsibilities or methods 20. What are Conceptual Classes? [CO3-L1-NOV/DEC2016] The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a conceptual class is an idea, thing, or object. More formally, a conceptual class may be considered in terms of its symbol, intension, and extension ß Symbol words or images representing a conceptual class. ß Intension the definition of a conceptual class. ß Extension the set of examples to which the conceptual class applies 21. How to Create a Domain Model? [CO3-L1-NOV/DEC2016] The current iteration requirements under design: 1. Find the conceptual classes (see a following guideline). 2. Draw them as classes in a UML class diagram. 3. Add associations and attributes. 22. How to Find Conceptual Classes? [CO3-L1-NOV/DEC2016] 1. Reuse or modify existing models. This is the first, best, and usually easiest approach, and where I will start if I can. There are published, well-crafted domain models and data models (which can be modified into domain models) for many common domains, such as inventory, finance, health, and so forth. Example books that I'll turn to include Analysis Patterns by Martin Fowler, Data Model Patterns by David Hay, and the Data Model Resource Book (volumes 1 and 2) by Len Silverton. 2. Use a category list. 3. Identify noun phrases 23. Define Association. [[CO3-L1-NOV/DEC2014] An association is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection. 24. What is Aggregation? [CO3-L1-NOV/DEC2016] Aggregation is a vague kind of association in the UML that loosely suggests wholepart relationships (as do many ordinary associations). It has no meaningful distinct Computer Science Engineering Department 30 Object Oriented Analysis and Design

31 semantics in the UML versus a plain association, but the term is defined in the UML. 25. What is composition? [CO3-L1-NOV/DEC2014] Composition, also known as composite aggregation, is a strong kind of whole-part aggregation and is useful to show in some models. A composition relationship implies that 1) an instance of the part (such as a Square) belongs to only one composite instance (such as one Board) at a time, 2) the part must always belong to a composite (no free-floating Fingers), and 3) the composite is responsible for the creation and deletion of its parts either by itself creating/deleting the parts, or by collaborating with other objects. PART-B 1. Explain about NextGen POS system. USECASE MODELING: The Use Case Model describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example login to system, register with system and create order are all Use Cases. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behavior. Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work. Actors: An Actor is a user of the system. This includes both human users and other computer systems. An Actor uses a Use Case to perform some piece of work which is of value to the business. The set of Use Cases an actor has access to defines their overall role in the system and the scope of their action.constraints, Requirements and Scenarios The formal specification of a Use Case includes: 1. Requirements: These are the formal functional requirements that a Use Case must provide to the end user. They correspond to the functional specifications found in structured methodologies. A requirement is a contract that the Use Case will perform some action or provide some value to the system. 2. Constraints: These are the formal rules and limitations that a Use Case operates under, and includes pre-post- and invariant conditions. A pre-condition specifies what must have already occurred or be in place before the Use Case may start. A post-condition documents what will be true once the Use Case is complete. An invariant specifies what will be true throughout the time the Use Case operates. 3.Scenarios: Computer Science Engineering Department 31 Object Oriented Analysis and Design

32 Scenarios are formal descriptions of the flow of events that occurs during a Use Case instance. These are usually described in text and correspond to a textual representation of the Sequence Diagram. USE CASE RELATIONSHIPS. Use case relationships is divided into three types 1. Include relationship 2. Extend relationship 3. Generalization 1. Include relationship: It is common to have some practical behavior that is common across several use cases. It is simply to underline it or highlight it in some fashion Example: Paying by credit: Include Handle Credit Payment 2. Extend relationship: Extending the use case or adding new use case to the process Extending use case is triggered by some conditions called extension point. 3. Generalization: Complicated work and unproductive time is spending in this use case relationship. Use case experts are successfully doing use case work without this relationship. Includes and Extends relationships between Use Cases One Use Case may include the functionality of another as part of its normal processing. Generally, it is assumed that the included Use Case will be called every time the basic path is run. An example may be to list a set of customer orders to choose from before modifying a selected order in this case the <list orders> Use Case may be ncluded every time the <modify order> Use Case is run. A Use Case may be included by one or more Use Cases, so it helps to reduce duplication of functionality by factoring out common behavior into Use Cases that are re-used many times. One Use Case may extend the behavior of another - typically when exceptional circumstances are encountered. Relationships Between Use CasesUse cases could be organized using following relationships: Generalization Association Extend Include Generalization Between Use Cases Generalization between use cases is similar to generalization between classes; child use case inherits properties and behavior of the parent use case and may override the behavior of the parent. 2. Explain about inception. [CO3-L1-NOV/DEC2016] Computer Science Engineering Department 32 Object Oriented Analysis and Design

33 NOTATION: Generalization is rendered as a solid directed line with a large open arrowhead (same as generalization between classes). Generalization between use cases Association Between Use Cases Use cases can only be involved in binary Associations. Two use cases specifying the same subject cannot be associated since each of them individually describes a complete usage of the system. Extend Relationship Extend is a directed relationship from an extending use case to an extended use case that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the use case to be extended. The extension takes place at one or more extension points defined in the extended use case. The extend relationship is owned by the extending use case. The same extending use case can extend more than one use case, and extending use case may itself be extended. Extend relationship between use cases is shown by a dashed arrow with an open arrowhead from the extending use case to the extended (base) use case. The arrow is labeled with the keyword Registration use case is meaningful on its own, and it could be extended with optional Get Help On Registration use case. The condition of the extend relationship as well as the references to the extension points are optionally shown in a Note attached to the corresponding extend relationship. Registration use case is conditionally extended by Get Help On Registration use case in extension point Registration Help Include Relationship. An include relationship is a directed relationship between two use cases, implying that the behavior of the required (not optional) included use case is inserted into the behavior of the including (base) use case. Including use case depends on the addition of the included use case. The include relationship is intended to be used when there are common parts of the behavior of two or more use cases. This common part is extracted into a separate use case to be included by all the base use cases having this part in common. As the primary use of the include relationship is to reuse common parts, including use cases are usually not complete by themselves but dependent on the included use cases. Include relationship between use cases is shown by a dashed arrow with an open arrowhead from the including (base) use case to the included (common part) use case. The arrow is labeled with the keyword «include». 3. Discuss about conceptual classes description classes with examples. The class diagram is the main building block of object oriented modelling. It is used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code. Class diagrams can also be used for data modeling. The classes in a class diagram represent both the main objects, interactions in the application and the classes to be programmed. A class with three sections. Computer Science Engineering Department 33 Object Oriented Analysis and Design

34 In the diagram, classes are represented with boxes which contain three parts: The top part contains the name of the class. It is printed in bold and centered, and the first letter is capitalized. The middle part contains the attributes of the class. They are left-aligned and the first letter is lowercase. The bottom part contains the methods the class can execute. They are also left-aligned and the first letter is lowercase. In the design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the static relations between those objects. With detailed modelling, the classes of the conceptual design are often split into a number of subclasses. 4. Explain about association and attributes. [CO3-L1-NOV/DEC2016] ASSOCIATIONS,ATTRIBUTES,AGGREGATION AND COMPOSITION: UML CLASS DIAGRAM: ASSOCIATION, AGGREGATION AND COMPOSITION The UML Class diagram is used to visually describe the problem domain in terms of types of object (classes) related to each other in different ways. There are three primary inter-object relationships: association, aggregation, and composition. Using the right relationship line is important for placing implicit restrictions on the visibility and propagation of changes to the related classes, matter which play major role in reducing system complexity. Association The most abstract way to describe static relationship between classes is using the Association link, which simply states that there is some kind of a link or a dependency between two classes or more. Computer Science Engineering Department 34 Object Oriented Analysis and Design

35 Weak Association ClassA may be linked to ClassB in order to show that one of its methods includes parameter of ClassB instance, or returns instance of ClassB. AGGREGATION (SHARED ASSOCIATION) In cases, where there s a part-of relationship between ClassA (whole) and ClassB (part), we can be more specific and use the aggregation link instead of the association link, taking special notice that ClassB can also be aggregated by other classes in the application (therefore aggregation is also known as shared association). So basically, the aggregation link doesn t state in any way that ClassA owns ClassB nor that there is a parent-child relationship (when parent deleted all its child s are being deleted as a result) between the two. Actually, quite the opposite! The aggregation link usually used to stress the point that ClassA is not the exclusive container of ClassB, as in fact ClassB has another container. In cases where in addition to the part-of relationship between ClassA and ClassB Computer Science Engineering Department 35 Object Oriented Analysis and Design

36 - there s a strong life cycle dependency between the two, meaning that when ClassA is deleted then ClassB is also deleted as a result, we should be more specific and use the composition link instead of the aggregation link or the association link. The composition link shows that a class (container, whole) has exclusive ownership over other class/s (parts), meaning that the container object and its parts constitute a parent-child/s relationship. Unlike association and aggregation, in the composition relationship, the composed class cannot appear as a return type or parameter type of the composite class, thus changes in the composed class cannot be propagated to the rest of the system. Consequently, usage of composition limits complexity growth as the system grows. SIGNIFICANCE: -Provides standard for software development. - Reducing of costs to develop diagrams of UML using supporting tools. - Development time is reduced. - The past faced issues by the developers are no longer exists. - Has large visual elements to construct and easy to follow. 5. Briefly discuss about elaboration use case modeling. [CO3--NOV/DEC2014] A domain model captures the most important types of objects in the context of the business. The domain model represents the things that exist or events that transpire in the business environment. Gives a conceptual framework of the things in the problem space Helps you think focus on semanticsprovides a glossary of terms noun based It is a static view - meaning it allows us convey time invariant business rules Foundation for use case/workflow modeling. Based on the defined structure, we can describe the state of the problem domain at any time. Features of a domain model Computer Science Engineering Department 36 Object Oriented Analysis and Design