INTERNAL ASSESSMENT TEST III Answer Schema

Similar documents
Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1

Software Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.

Design Patterns. An introduction

Objectives. Explain the purpose and objectives of objectoriented. Develop design class diagrams

What is a Pattern? Lecture 40: Design Patterns. Elements of Design Patterns. What are design patterns?

Topic : Object Oriented Design Principles

Design Pattern. CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.)

Goals of Lecture. Lecture 27: OO Design Patterns. Pattern Resources. Design Patterns. Cover OO Design Patterns. Pattern Languages of Programming

OBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization

Chapter 10 Object-Oriented Design Principles

EPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns

Design of Software Systems (Ontwerp van SoftwareSystemen) Design Patterns Reference. Roel Wuyts

Object-Oriented Design

Keywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator.

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar

Idioms and Design Patterns. Martin Skogevall IDE, Mälardalen University

Object-Oriented Oriented Programming Adapter Pattern. CSIE Department, NTUT Woei-Kae Chen

Socket attaches to a Ratchet. 2) Bridge Decouple an abstraction from its implementation so that the two can vary independently.

Facade and Adapter. Comp-303 : Programming Techniques Lecture 19. Alexandre Denault Computer Science McGill University Winter 2004

SOFTWARE PATTERNS. Joseph Bonello

Lecture 13: Design Patterns

Design Patterns Design patterns advantages:

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Pattern Resources. Lecture 25: Design Patterns. What are Patterns? Design Patterns. Pattern Languages of Programming. The Portland Pattern Repository

Design Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011

Object-Oriented Design

LECTURE NOTES ON DESIGN PATTERNS MCA III YEAR, V SEMESTER (JNTUA-R09)

SDC Design patterns GoF

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

Foundations of Software Engineering Design Patterns -- Introduction

Object-Oriented Oriented Programming Adapter Pattern

Chapter 5 Object-Oriented Programming

Object Oriented Paradigm

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar

Appendix A - Glossary(of OO software term s)

Design Patterns. Comp2110 Software Design. Department of Computer Science Australian National University. Second Semester

ADAPTER. Topics. Presented By: Mallampati Bhava Chaitanya

CSC207H: Software Design Lecture 6

OBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization

Design Patterns IV Structural Design Patterns, 1

Object-oriented Software Design Patterns

Design Patterns. GoF design patterns catalog

Software Engineering

Coordination Patterns

COURSE 4 DESIGN PATTERNS

Software Design COSC 4353/6353 D R. R A J S I N G H

Applying Design Patterns to accelerate development of reusable, configurable and portable UVCs. Accellera Systems Initiative 1

Object-Oriented Systems Analysis and Design Using UML

Design Patterns IV. Alexei Khorev. 1 Structural Patterns. Structural Patterns. 2 Adapter Design Patterns IV. Alexei Khorev. Structural Patterns

Using Design Patterns in Java Application Development

The Strategy Pattern Design Principle: Design Principle: Design Principle:

Adapter Pattern Structural

Review Software Engineering October, 7, Adrian Iftene

Topics in Object-Oriented Design Patterns

DESIGN PATTERNS SURESH BABU M ASST PROFESSOR VJIT

Design Patterns. Gunnar Gotshalks A4-1

Design Patterns. CSE870: Advanced Software Engineering (Design Patterns): Cheng

The Unified Modeling Language. Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL

CS342: Software Design. November 21, 2017

Ingegneria del Software Corso di Laurea in Informatica per il Management. Design Patterns part 1

In this Lecture you will Learn: Design Patterns. Patterns vs. Frameworks. Patterns vs. Frameworks

Design Patterns! Acknowledgements!

Design patterns. Jef De Smedt Beta VZW

A Reconnaissance on Design Patterns

Object Oriented Analysis and Design - Part2(Design)

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Produced by. Design Patterns. MSc in Computer Science. Eamonn de Leastar

Design Patterns. Dr. Rania Khairy. Software Engineering and Development Tool

Software Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software

Lecture 20: Design Patterns II

Design Patterns V Structural Design Patterns, 2

Introduction to Unified Modelling Language (UML)

Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/03/2015

LABORATORY 1 REVISION

CSCI 253. Overview. The Elements of a Design Pattern. George Blankenship 1. Object Oriented Design: Iterator Pattern George Blankenship

Design Patterns: Elements of Reusable Object Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

1 of 27 9/27/2001 5:34 PM

Summary of the course lectures

GRASP Design Patterns A.A. 2018/2019

SOFTWARE ENGINEERING SOFTWARE DESIGN. Saulius Ragaišis.

Notation Part 1. Object Orientated Analysis and Design. Benjamin Kenwright

Design Patterns. Lecture 10: OOP, autumn 2003

What are patterns? Design Patterns. Design patterns. Creational patterns. The factory pattern. Factory pattern structure. Lecture 10: OOP, autumn 2003

Chapter 8: Class and Method Design

DESIGN PATTERN - INTERVIEW QUESTIONS

Design Patterns Reid Holmes

Cocoa Design Patterns. Erik M. Buck October 17, 2009

Slide 1. Design Patterns. Prof. Mirco Tribastone, Ph.D

Introduction to Design Patterns

What are the characteristics of Object Oriented programming language?

CSE 70 Final Exam Fall 2009

Introduction to Design Patterns

1 Executive Overview The Benefits and Objectives of BPDM

A Rapid Overview of UML

DESIGN PATTERNS Course 4

UNIT V *********************************************************************************************

Designing Component-Based Architectures with Rational Rose RealTime

Unit Wise Questions. Unit-1 Concepts

Recap : UML artefacts. Black Box Requirements. Functional Specification. System. System. Test. Design. System. System. Development.

Transcription:

INTERNAL ASSESSMENT TEST III Answer Schema Subject& Code: Object-Oriented Modeling and Design (15CS551) Sem: V ISE (A & B) Q. No. Questions Marks 1. a. Ans Explain the steps or iterations involved in object oriented design process. 1. Create a Preliminary version or a first-cut model of the design class diagrams. 2. Develop interaction diagrams for each use case or scenario: Sequence diagram and communication diagram. 3. Update the design class diagrams 4. Partition the design class diagrams into related functions using package diagrams b. Ans Explain with an example the standard stereotypes found in design model. Stereotypes: UML notation to categorize a model element as a certain type Standard stereotypes: Entity, control, boundary, data access Entity class: Comes from the domain model. Normally passive- wait for business events to occur. Persistent class- data must persist after the system is shut down Boundary class: Specifically designed to live on the system s automation boundary Example: Classes associated with the user interface Control class: Class that mediates between the boundary class and the entity classes Responsibility to catch the messages from the boundary class objects and send them to the correct entity class objects Data access class: Class that is used to retrieve data from and send data to a database 2 Define the following: a. Encapsulation and Information hiding Each object is a self-contained unit containing both data and program logic. Data associated with an object is not visible i.e., object attributes are private. Methods provide access to data and to modify them. b. Navigation visibility Describes which objects can view and interact with each other. c. Coupling Measures how closely classes are linked. Number of navigation arrows on the DCD

Low coupling better than high coupling. Fewer navigations indicate that a system is easier to understand and maintain. d. Cohesion: Measures the consistency of functions in a class 3 Develop a complete three layer sequence diagram for Look up item availability use case. 4 a. b. Ans Describe the major difference between sequence diagram and communication diagram. Communication Diagram focuses on Object themselves. Drawing an Communication Diagram is an effective way to get a quick overview of the collaborating objects. However, You have to hunt to find the numbers to see the sequence of the Messages. Communication Diagrams are used to sketch out a solution. If the Use Case is small and not too complex a simple Communication Diagram may suffice. For more complex situations, Sequence Diagram may be required to allow you visualize the flow and Message sequence. You can mix the usage of both Interaction Diagrams within the same set of specifications. What are the major implementation issues for a three layer design? The Problem with IDE Tool approach is the difficulty of maintaining the System Codes since they scattered throughout the Graphical Use Interface (GUI) Classes, that becomes very hard to find and maintain. If a Network-based System needs to be enhanced to include Web- front end then a Programmer must rebuild nearly the entire System. If two User Interfaces are desired, then all of the Business Logic is programmed twice. We recommend that the would be Analysts and Programmers should use Good Design Principles in the Development of new Systems. 5 Explain with an example the purpose of package diagram along with the UML notations used. Package Diagram is a high level Diagram that allows the Designer to associate classes of related groups. A Package Diagram can group Classes by Subsystem or by Layer (View Layer, Domain Layer and Data Access Layer). To develop Package

Diagram extract information from Updated Design Class Diagram and Interaction Diagram (Sequence Diagram) for each Use Case. Place the Classes inside the appropriate Packages based on the Layer or Subsystem to which they belong. Dependency Relationships (Dashed arrow line ) shows which elements affect other elements in a System. The arrow tail is connected to the Package that is dependent. And the arrow head is connected to the independent Package. Dependence Relationship may exist between Packages, or between Classes within Packages. Dependency Relationship help designer to track the carry-through effect of changes. Package Diagrams can also be nested to show different level of Packages. The Benefit of using the Package Diagrams for Documentation is that different Packages can be assigned to different Programming teams to program the Classes. Dependency arrow will help Designers recognize where communication among teams must occur to ensure a totally integrated system. 6 What is a design pattern? Explain the four essential elements of design pattern. A design pattern is a general reusable solution to a commonly occurring problem in software design. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. four elements. Pattern name: A handle used to describe: a design problem, its solutions, its consequences. Increases design vocabulary. Makes it possible to design at a higher level of abstraction. Enhances communication Problem: Describes when to apply the pattern. Explains the problem and its context. May describe specific design problems and/or object structures. May contain a list of preconditions that must be met before it makes sense to apply the pattern. Solution: Describes the elements that make up the: design, relationships, responsibilities, collaborations. Does not describe specific concrete implementation. Abstract description of design problems and how the pattern solves it Consequences: Results and trade-offs of applying the pattern. Critical for: evaluating design alternatives, understanding costs, understanding benefits of applying the pattern. Includes the impacts of a pattern on a system s: flexibility,

extensibility, portability. 7 How design patterns solve design problems? Discuss. 1. Finding Appropriate Objects 2. Determining Object Granularity 3. Specifying Object Interfaces 4. Specifying Object Implementations 5. Putting Reuse Mechanisms to Work 6. Relating Run-Time and Compile-Time Structures. 7. Designing for Change What are the common causes for redesign? Explain in detail Creating an object by specifying a class explicitly. Dependence on specific operations. Dependence on hardware and software platform Dependence on object representations or implementations Algorithm dependencies Tight Coupling Extending functionality by subclassing Inability to alter conveniently 9 With an example discuss the implementation issues considered when using a singleton design pattern. Ensuring a unique instance: The Singleton pattern makes the sole instance a normal instance of a class, but that class is written so that only one instance can ever be created. A common way to do this is to hide the operation that creates the instance behind a static class operation that guarantees that only one instance is created. class Singleton { private static Singleton instance; static Singleton Instance() {if (instance == null) // if not created yet instance = new Singleton(); // create once return instance; } Sub classing the singleton class: registry of singleton: Instead of having Instance define the set of possible Singleton classes, the Singleton classes can register their singleton instance by name in a well-known registry. The registry maps between string names and singletons. When Instance needs a singleton, it consults the registry, asking for the singleton by name. The registry looks up the corresponding singleton (if it exists) and returns it. This approach frees Instance from knowing all possible Singleton classes or instances. All it requires is a common interface for all Singleton classes that includes operations for the registry: class Singleton { public:

static void Register(const char* name, Singleton*); static Singleton* Instance(); protected: static Singleton* Lookup(const char* name); private: static Singleton* _instance; static List<NameSingletonPair>* _registry; }; 10 Write Short notes on: a. Adapter: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. It is also known as wrapper. Use the Adapter pattern when you want to use an existing class, and its interface does not match the one you need. you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces. (object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class. Structure: A class adapter uses multiple inheritance to adapt one interface to another: implementation of Adapter: Implementing class adapters in C++. Pluggable adapters : Using abstract operations, Using delegate objects, parameterized object b. Proxy: Provide a surrogate or placeholder for another object to control access to it. It is also known as surrogate.

Proxy pattern is applicable: remote proxy, virtual proxy, protection proxy and smart references Structure: Proxy pattern can be implemented by Overloading the member access operator in C++. Using doesnotunderstand in Smalltalk Proxy doesn't always have to know the type of real subject