Ooad Unit I

OBJECT-ORIENTED ANALYSIS AND DESIGN
UNIT I
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak
U1. #
Learning Objectives
The Object-Oriented Paradigm Object-Oriented approach characteristics Traditional versus Modern Object-Oriented Paradigm Key Aspects of Object-Oriented Solution Benefits of OO approach Drawbacks of OO approach Case Study Object Oriented Basic Terms
U1. #
Why object orientation? To create sets of objects that work together concurrently to produce s/w that better, model their problem domain that similarly system produced by traditional techniques. - It adapts to 1. Changing requirements 2. Easier to maintain 3. More robust 4. Promote greater design 5. Code reuse - Higher level of abstraction -- Encouragement of good programming techniques - Promotion of reusability
U1. #
Benefits of Object Orientation Faster development, Reusability, Increased quality Object technology emphasizes modeling the real world and provides us with the stronger equivalence of the real worlds entities (objects) than other methodologies.
U1. #
Object: In an object-oriented system, everything is an object: numbers, arrays, records, fields, files, forms, an invoice, etc. An Object is anything, real or abstract, about which we store data and those methods that manipulate the data. A window object is responsible for things like opening, sizing, and closing itself. A chart object is responsible for things like maintaining its data and labels, and even for drawing itself.
U1. #
Objects Attributes Attributes represented by data type. They describe objects states. In the Car example the cars attributes are: color, manufacturer, cost, owner, model, etc. Objects Methods Methods define objects behavior and specify the way in which an Objects data are manipulated. In the Car example the cars methods are: drive it, lock it,carry passenger in it.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak U1. #
Objects are Grouped in Classes The role of a class is to define the attributes and methods (the state and behavior) of its instances. The class car, for example, defines the property color. Each individual car (object) will have a value for this property, such as "maroon," "yellow" or "white."
U1. #
Class Hierarchy An object-oriented system organizes classes into subclass-super hierarchy. At the top of the hierarchy are the most general classes and at the bottom are the most specific A subclass inherits all of the properties and methods (procedures) defined in its super class.
U1. #
U1. #
OBJECT
An object can be an item, place, person or any other entity. All objects have the following characteristics: Identity: The name associated with an object helps in identifying the object. Example: Play-Ground, Multiplexes, Wall-clock, Class-Room, Court-Room.
U1. #
OBJECT
State: An object can be in many state. Example: TV can be in the following states: (a) On State. (b) Off State. Out of order state. Behavior : What the object does or what is it capable of doing? Example: A person can sit, stand, read, sleep, walk & talk etc. Similarly, a cup can be filled, drunk from, washed, broken etc.
OBJECT
Object is an identifiable entity with some Characteristics & Behavior. Example: Orange is an Object. Characteristics / Data : (1) Spherical shaped (2) Color Orange Behavior / Functions: (1) It is Juicy. (2) It tastes sweet-sour.
U1. #
U1. #
OBJECT
Objects are the basic run time entities in an object oriented system. They match closely with real time objects. Objects take up space in memory and have an associated address like a Record in Pascal and a Structure in C. Objects interact by sending Message to one other. E.g. If Customer and Account are two objects in a program then the customer object may send a message to the account object requesting for bank balance without divulging the details of each others data or code.
U1. #
Objects
An object is an entity which has a state and a defined set of operations which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects (clients) which request these services when some computation is required. Objects are created according to some object class definition. An object class definition serves as a template for objects. It includes declarations of all the attributes and services which should be associated with an object of that class.
U1. #
OBJECT VISIBILITY
U1. #
CLASS
A class is a group of objects that share common properties & behavior/ relationships. In fact, objects are the variables of the type class. After creating class, one can create any no. of related objects with that class. Classes are user defined data types and behaves like the built-in types of a programming language.
U1. #
CLASS
The syntax used to create an object is similar to create an object integer in C. Example: fruit mango; class employee; Class: Employee; States / Data : Name, Dept, Desig, Basic Behavior / Functions: setbp( ), totsal( ), deduction( )
U1. #
Class Diagram of Employee class

Class: employee Data: Name Dept Desig Basic
Functions: Setbp( ) Totsal( ) Deductions( )

U1. #
U1. #
U1. #
U1. #
U1. #
ABSTRACTION
It refers to the act of representing essential features without including the background details or explanations. Example: Switch Board, Railway reservation, Milk Vending machine, Driving a car etc.
Explanation (Driving a Car): (Need to Know): Gear handling, Steering Clutch, Brakes, Accelerator etc. (Not Necessary to know): Internal details Engine details & functions. handling, Use of like wiring,
U1. #
U1. #
ENCAPSULATION
The wrapping up of data & functions (that operate on the data) into a single unit (called class) is known as ENCAPSULATION. Encapsulation is a way to implement data abstraction. Example: Departmental data, ATM cash counter, Weighing Machine etc. Only Relevant details are exposed and rest are made hidden. [Data Security]
INHERITANCE
Inheritance is the capability of one class of things to inherent properties from other class. Supports the concept of Hierarchial classification. Ensures the closeness with real world models. Provides Multiple Access Specifiers across the modules (Public, Private & Protected) Supports Reusability that allows the addition of extra features to an existing class without modifying it.
U1. #
U1. #
POLYMORPHISM / OVERLOADING
A Greek term suggest the ability to take more than one form. It is a property by which the same message can be sent to the objects of different class. Example: Draw a shape (Box, Triangle, Circle etc.), Move ( Chess, Traffic, Army).
U1. #
POLYMORPHISM (Contd.)
Allows to create multiple definition for operators & functions. Example: + is used for adding numbers / to concatenate two string / Sets of Union and so on. Dynamic Binding/ Late Binding. Run-time dependent. Execution depends on the base of a particular definition.
U1. #
Object Diagrams
Object Diagrams describe the static structure of a system at a particular time. Whereas a class model describes all possible situations, an object model describes a particular situation. Object diagrams contain the following elements:
Objects, which represent particular entities. These are instances of classes. Links, which represent particular relationships between objects. These are instances of associations.
Application Areas of OOPS

Real time systems. Simulation & Modelling. Object-oriented database system. Object-oriented Operating System. Graphical User Interface. Window based O.S. design. Multimedia Design. CAD/CAM. Computer based Training & Education System.
U1. #
Merits of object approach

- Object orientation works at a higher level of abstraction One of our most powerful techniques is the form of selective amnesia called 'Abstraction'. Abstraction allows us to ignore the details of a problem and concentrate on the whole picture. - Software life cycle requires no vaulting The object-oriented approach uses essentially the same language to talk about analysis,design, programming and (if using an Object-oriented DBMS) database design. This streamlines the entire software development process, reduces the level of complexity and redundancy, and makes for a cleaner system architecture and design.
U1. #
Data is more stable than functions Functions are not the most stable part of a system, the data is. Over a period of time, the requirements of a system undergo radical change. New uses and needs for the software are discovered; new features are added and old features are removed. During the course of all this change, the underlying heart of the system remains comparatively constant. This heart is the data Encourages good programming techniques
U1. #
- Promotes code reuse The code and designs in object-oriented software development are reusable because they are modeled directly out of the real-world problem-domain. Structured approach focuses on functions Object approach focuses on Object. (data) Good quality software is Correct Robust Extendible Reusable -- Compatible
Pitfalls of top-down design - Functional viewpoint is difficult to evolve - Real systems are hard to characterize functionally - Functional approach loses focus of data - Traditional approach produces less reusable code
U1. #
The Object Model

Object-Oriented technology is built upon a sound engineering foundation, whose elements are collectively call the object model. The object model encompasses the principles of abstraction, encapsulation, modularity, hierarchy , typing , concurrency, and persistence. Object-oriented analysis (OOA) is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain . Object-oriented design (OOD) is a method of design encompassing the process of Object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design. Object-oriented programming (OOP) is a method of implementation in which programs are organized as cooperative collection of objects each of which represents an instance of some classes are all members of a hierarchy of classes united via inheritance relationships.
An abstraction denotes the essential characteristics of an object that distinguishes it from all other kinds of objects and thus provide crisply-defined, conceptual boundaries, relative to the perspective of the viewer; the process of focusing upon the essential characteristics of an object. Abstraction and encapsulation are complementary concepts. Abstractions focus upon the observable behavior of an object, whereas encapsulation is most often achieved through information hiding, which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics. Typically, the structure of an object is hidden, as well as the implementation of its methods.
U1. #
Structured Analysis In Structured Analysis, the focus is only on process and procedures. Modeling techniques used in it are DFD(Data Flow Diagram), Flowcharts,data dictionaries ,decision trees ,decision tables, structure charts etc. This approach is old and is not preferred
U1. #
Transition From Analysis to Design
Traditional paradigm: Jolt between analysis (what) and design (how) Object-oriented paradigm: Objects enter from very beginning
Analysis/Design
Systems analysis
Determine what has to be done Determine the objects
Design
Determine how to do it Design the objects Detailed designdesign each module
U1. #
In More Detail
Objects enter here

Object Oriented Analysis Whereas in Object Oriented Analysis, the focus is more on capturing the real world objects in the current scenario that are of importance to the system. It stresses more on data structure and less on procedural structure. In this approach, objects are identified, their relationships among each other, possible states that each object can be in, and finally how all objects collaborate with each other to achieve a broader system goal are identified. Modeling techniques used in it are UML(Unified modeling Language), that can present both structural and behavioural/procedural aspect of the system. UML includes Class Diagram, State Diagram, Use case diagram, Sequence Diagram, etc.
OOA Phase
Overall question is What? Do not worry about the implementation details The focus is on the real world What are the objects and classes in my program? What the responsibilities of them? In the OOA phase, the overall questions is "What?". As in, "What will my program need to do?", "What will the classes in my program be?", and "What will each class be responsible for?". You do not worry about implementation details in the OOA phase -- there will be plenty of time to worry about them later, and at this point they only get in the way. The focus here is on the real world -- what are the objects, tasks and responsibilities of the real system?
What to do during OOA?

Determine the functionality of the system, usually called requirements analysis. Create a list of what classes are part of the system, and (just as important) what classes are not part of the system. Distribute the functionality of the system among the list of classes. A piece of functionality assigned to a specific class is called a responsibility
U1. #
OOA(By Coad)- Method

OOA uses basic structuring principles, and joins them with an object-oriented point of view. The method consists of five steps: 1) Finding Class & Object - specifies how classes and objects should be found. The first approach is given by starting with the application domain and identifying the classes and objects forming the basis of the entire application and, in the light of this, the systems responsibilities in this domain are analysed.
2) Identifying Structures -
this is done in two different ways. First, the generalisationspecialisation structure, which captures the hierarchy among the identified classes. Second, the Whole-Part structure, which is used to model how an object is part of another object, and how objects are composed into larger categories.
3) Defining Subjects -
this is done by partitioning the Class & Object model into larger units. Subjects are groups of Class & Object. The structures identified earlier can be used. 4) Defining Attributes - this is done by identifying information and associations for every instance. This involves identifying the attributes needed to characterise each object. The identified attributes are placed at the correct level in the inheritance hierarchy.
5) Defining Services -
defining the operations of the classes. This is done by identifying the object states and defining services for accessing and altering that state.
In the OOD phase, the overall question is "How?". As in, "How will this class handle it's responsibilities?", "How can I ensure that this class knows all the information it needs?", "How will classes in my design communicate?". At this point, you are worried about some implementation details, but not all -- what the attributes and methods of a class will be.
U1. #
The essence of Object-oriented Analysis and Design is to emphasize considering a problem domain and logical solution from the perspective of objects (things, concepts, or entities) as shown in figure below. Analysis
Investigation of the problem
Design
Logical solution
construction
Code
U1. #
During Object-oriented Analysis ,there is an emphasis on finding and describing the objects-or concepts-in the problem domain. For example ,in the case of the library information system, some of the concepts include books ,library and students.
U1. #
U1. #
Finally, during construction or object-oriented programming, design components are implemented, such as a book class in C++, java, smalltalk, or visual basic.
The OO and SADT methods provide their own representational notations for constructing a set of models during the development life cycle for a given system.
U1. #
U1. #
Requirements Requirements capture is about discovering what is going to achieve with new piece of software. Analysis Analysis means understanding what are dealing with. Before designing a solution, it needs to be clear about the relevant entities, their properties and their interrelationships. This can involve customers and end users, since theyre likely to be subject-matter experts
U1. #
Design
In the design phase, will work out, how to solve the problem. In other words, make decisions based on experience, estimation and intuition, about what software which will write and how will deploy it. System design breaks the system down into logical subsystems (processes) and physical subsystems (computers and networks), decides how machines will communicate, and chooses the right technologies for the job
U1. #
Implementation In this phase is writing pieces of code that work together to form subsystems, which in turn collaborate to form the whole system. Testing When the software is complete, it must be tested against the system requirements to see if it fits the original goals.
U1. #
The Unified Approach (UA)

UA based on methodologies by Booch, Rumbaugh and Jacobson tries to combine the best practices, processes and guidelines along with the object management groups in unified modelling language. UA utilizes the unified modeling language (UML) which is a set of notations and conventions used to describe and model an application. Goals: Define Objects and classes Describe objects methods, attributes and how objects respond to messages, Define Polymorphism, Inheritance, data abstraction, encapsulation, and protocol Describe objects relationships,
Object-Oriented Software Engineering: Objectory Object-oriented software engineering (OOSE), also called Objectory, is a method of object-oriented development with the specific aim to fit the development of large, real-time systems. Objectory is built around several different models: Use case model. Domain object model. Analysis object model. Implementation model. Test model
U1. #
U1. #
U1. #
Two different models are developed in analysis; the Requirements Model and the Analysis Model. These are based on requirement specifications and discussions with the prospective users. The first model, the Requirements Model, should make it possible to define the system and to define what functionality should take place within it. For this purpose we develop a conceptual picture of the system using problem domain objects and also specific interface descriptions of the system if it is meaningful for this system. We also describe the system as a number of use cases that are performed by a number of actors.
The Analysis Model consisting of various object classes: control object, entity objects, and interface objects. The purpose of this model is to find a robust and extensible structure for the system as a base for construction. Each of the object types has its own special purpose for this robustness, and together they will offer the total functionality that was specified in the Requirements Model.
U1. #
Construction
We build our system through construction based on the Analysis Model and the Requirements Model created by the analysis process. The construction process lasts until the coding is completed and the included units have been tested. There are three main reasons for a construction process: 1) The Analysis Model is not sufficiently formal. 2) Adaptation must be made to the actual implementation environment. 3) We want to do internal validation of the analysis results.
U1. #
The construction activity produces two models, the Design Model and the Implementation Model. Construction is thus divided into two phases; design and implementation, each of which develops a model. The Design Model is a further refinement and formalization of the Analysis Model where consequences of the implementation environment have been taken into account. The Implementation model is the actual implementation (code) of the system.
U1. #
Testing
Testing is an activity to verify that a correct system is being built. Testing is traditionally an expensive activity, primarily because many faults are not detected until late in the development. To do effective testing we must have as a goal that every test should detect a fault
U1. #
Characteristics of OOD
Objects are abstractions of real-world or system entities and manage themselves Objects are independent and encapsulate state and representation information. System functionality is expressed in terms of object services Shared data areas are eliminated. Objects communicate by message passing Objects may be distributed and may execute sequentially or in parallel.ex-printer,Memory,CPU etc
U1. #
Advantages of OOD
Easier maintenance. Objects may be understood as stand-alone entities Objects are appropriate reusable components For some systems, there may be an obvious mapping from real world entities to system objects
U1. #
Polymorphism
is the quality that allows one name to be used for two or more related but technically different purposes. In the following, each graphical object has the same services, although they are implemented differently.
U1. #
Encapsulation
is the mechanism that binds together code and the data it manipulates and keeps both safe from outside interference and misuse. In the following, only the services move() and scale() modify the attributes of Circle. The service draw() performs some computation based on the values of the attributes.
U1. #
Classification is used to group entities that share common characteristics

into a class over which uniform conditions hold.
U1. #
Class Diagrams A graphical representation of a static view A central modeling technique that runs through nearly all object-oriented methods. The richest notation in UML. A class diagram shows the existence of classes and their relationships in the logical view of a system Essential Elements of a UML Class Diagram Class Attributes Operations Relationships Associations Generalization Dependency
U1. #
Classes
ClassName attributes
A class is a description of a set of objects that share the same attributes,operations, elationships, and semantics.
Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations in separate, designated compartments.
operations
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak Software Design (UML)
U1. #
Class Attributes (Contd)

Attributes are usually listed in the form: Person attributeName : Type A derived attribute is one that can be computed from other attributes, but doesnt actually exist. For example, a Persons age can be computed from his birth date. A derived attribute is designated by a preceding / as in: / age : Date name : String address : Address birthdate : Date / age : Date ssn : Id
U1. #
Class Attributes (Contd)

Person Attributes can be: + public # protected - private / derived + name : String # address : Address # birthdate : Date / age : Date - ssn : Id
U1. #
Class Operations
Person name : String address : Address birthdate : Date ssn : Id eat sleep work play Operations describe the class behavior and appear in the third compartment.
U1. #
What Is Multiplicity?
Multiplicity is the number of instances of one class relates to instance of another class. For each association, there are two multiplicity decisions to make, one for each end of the association.
For each instance of Professor, many Course Offerings may be taught. For each instance of Course Offering, there may be either one or zero Professor as the instructor.
<<entity>> instructor Professor 0..1
<<entity>> CourseOffering 0..* 0.. *
U1. #
Multiplicity Indicators
Unspecified Exactly one Zero or more (many, unlimited)
1 0..*
One or more Zero or one (optional scalar role) Specified range Multiple, disjoint ranges
1..* 0..1
2..4 2, 4..6
U1. #
A class is the description of a set of objects having similar attributes, operations, relationships and behavior Attributes Classes have attributes that describe the characteristics of their objects. Attributes are atomic entities with no responsibilities.
U1. #
Associations
A semantic relationship between two or more classes that specifies connections among their instances. Example: An Employee works for a Company An association can be viewed as a weak form of aggregation or as a data-oriented relationship between two entities. For example, if there is a car, it must be associated with an owner.
U1. #
An association model
Employee
is-member-of
Department
is-managed-by
manages
Manager
U1. #
Association Relationships
An aggregation specifies a whole-part relationship between an aggregate (a whole) and part, where the part can exist independently from the aggregate. Aggregations are denoted by a hollow-diamond adornment on the association.
Engine
Car
Transmission
U1. #
A composition indicates a strong ownership and coincident lifetime of parts by the whole (i.e., they live and die as a whole). Compositions are denoted by a filled-diamond adornment on the association.
Scrollbar
1 1
Window
1 1
Titlebar Menu
1 1 .. *
U1. #
U1. #
1-to-1 and 1-to-many Associations

Country
name:String Hascapital
City
name:String
One-to-one association
Workorder
StickyNote
schedule()
x: Integer y: Integer z: Integer
One-to-many association
If two classes in a model need to communicate with each other, there must be link between them. An association denotes that link.
Student
Instructor
U1. #
We can indicate the multiplicity of an association by adding multiplicity adornments to the line denoting the association. The example indicates that a Student has one or more Instructors:
Student
1..*
Instructor
U1. #
Association Relationships (Contd)
The example indicates that every Instructor has one or more Students:
Student
1..*
Instructor
U1. #

We can also indicate the behavior of an object in an association (i.e., the role of an object) using rolenames.
teaches Student 1..*
learns from 1..* Instructor
U1. #

We can also name the association.
membership Student 1..* 1..* Team
U1. #
We can specify dual associations.
member of 1..* Student

1
1..* Team
president of
1..*
U1. #
The goal of OO analysis is to identify objects and classes that support the problem domain and system's requirements. Some general candidate classes are: Persons Places Things Class Hierarchy Identify class hierarchy Identify commonality among the classes Draw the general-specific class hierarchy.
U1. #
Generalisation and inheritance

Objects are members of classes which define attribute types and operations Classes may be arranged in a class hierarchy where one class (a super-class) is a generalisation of one or more other classes (sub-classes) A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own Generalisation in the UML is implemented as inheritance in OO programming languages
U1. #
Inheritance
Models "kind of" hierarchy Powerful notation for sharing similarities among classes while preserving their differences UML Notation: An arrow with a triangle
Cell
BloodCell
MuscleCell
NerveCell
Red
White
Smooth
Striate
Cortical
Pyramidal
U1. #
A generalisation hierarchy
Employee
Ma nager budgetsControlled dateAppointed
Programmer project progLanguage
Project Ma nag er projects
De pt. Ma nager dept
Strategic Ma nag er responsibilities
U1. #
U1. #
U1. #
Inheritance is also called the generalization-specialization, gen-spec, or IsA hierarchy. Note that inheritance is a relationship between classes, not objects. Generalized classes are placed higher in the hierarchy while specialized ones are found below. For example, a Vehicle is a generalized class while TruckVehicle and CarVehicle are more specialized ones. In other words, a TruckVehicle is-a-kind-of Vehicle.
U1. #
Inheritance hierarchy. The generalized class at the top and the specialized classes below. The specialized class names should reflect the class they were specialized from. For example, employee was specialized from Person.
U1. #
A mechanism for expressing similarity among classes. It portrays generalization (What is the same?) and specialization (What is different?), making common attributes and services explicit within a class hierarchy.
U1. #
Aggregation
A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.
Aggregation is also called whole-part or HasA. For example, an Aircraft contains an Engine or in other words, an Aircraft has an Engine.
U1. #
For example, among other things, a car consists of tires and an engine. Note that the opposite of aggregation is decomposition.
U1. #
Aggregation Represents a has-a (whole-part) relationship An object of the whole has objects of the part
U1. #
Aggregation
Models "part of" hierarchy Useful for modeling the breakdown of a product into its component parts . UML notation: Like an association but with a small diamond indicating the assembly end of the relationship.
U1. #
Aggregation
Automobile
Engine horsepower volume on off serial number year manufacturer model color weight drive purchase 3,4,5 Wheel * 2,4
Brakelight
on off
Door
open close
Battery amps volts
diameter number of bolts
charge discharge
U1. #
A form of aggregation with strong ownership and coincident lifetime as part of the whole. Parts with non-fixed multiplicity may be created after the composite itself, but once created they live and die with it (i.e., they share lifetimes). Such parts can also be explicitly removed before the death of the composite.
U1. #
U1. #
U1. #
Aggregation is a relatively weaker form of the whole-part relationship, while composition is a relatively stronger form. Composition: Stronger * Composition, also known as the a-part-of , is a form of aggregation with strong ownership to represent the component of a complex object. Composition also is referred to as a part-whole relationship. The UML notation for composition is a solid diamond at the end of a path.
U1. #
Aggregation vs Inheritance
Both associations describe trees (hierarchies) Aggregation tree describes a-part-of relationships (also called and-relationship, Has a Relationship,containership) Inheritance tree describes "kind-of" relationships (also called or-relationship,is-a ) Aggregation relates instances (involves two or more different objects)
Inheritance relates classes (a way to structure the description of a single object)

Dependency
A dependency is a relation between two classes in which a change in one may force changes in the other although there is no explicit association between them. A stereotype may be used to denote the type of the dependency. Indicates a semantic relationship between two (or more) classes It indicates a situation in which a change to the target element may require a change to the source element in the dependency A dependency is shown as a dashed arrow between two model elements
U1. #
Employee class (UML)

Employee name: string address: string dateOfBirth: Date employeeNo: integer socialSecurityNo: string department: Dept ma nager: Employee salary: integer status: {current, left, retired} taxCode: integer . .. join () leave () retire () changeDetails ()
Class Identification
Identify the boundaries of the system Identify the important entities in the system Class identification is crucial to object-oriented modeling Basic assumption: 1. We can find the classes for a new software system (Forward Engineering) 2. We can identify the classes in an existing system (Reverse Engineering)
U1. #
Representing Classes in the UML

A class is represented using a rectangle with compartments.
Professor
- name - employeeID : UniqueId - hireDate - status - discipline - maxLoad + submitFinalGrade() + acceptCourseOffering() + setMaxLoad() + takeSabbatical()
Professor Amit
U1. #
Representing Objects in the UML

An object is represented as a rectangle with an underlined name.
Amit Professor
Named Object
: Professor
Professor Amit Unnamed Object
U1. #
UML: Class and Instance Diagrams

Inspector
Class Diagram
joe: Inspector
mary: Inspector
anonymous: Inspector
Instance Diagram
U1. #
Attributes and Values

Inspector name:string age: integer
joe:Inspector name = Joe age = 24
mary: Inspector
name = Mary age = 18
U1. #
Class Attributes
Person name : String address : Address birthdate : Date ssn : Id
An attribute is a named property of a class that describes the object being modeled. In the class diagram, attributes appear in the second compartment just below the name-compartment.
Bharati Vidyapeeths Institute of Computer Applications and Management, New Delhi-63, by Nitish Pathak Software Design (UML) U1. #
Class Diagram
Captures the vocabulary of a system
U1. #
U1. #
U1. #
U1. #
U1. #
U1. #
Class Diagram
U1. #
U1. #
U1. #
U1. #
U1. #
Object Oriented Methodologies
U1. #
Object Oriented Methodology (OOM) is a system development approach encouraging and facilitating re-use of software components. With this methodology, a computer system can be developed on a component basis which enables the effective re-use of existing components and facilitates the sharing of its components by other systems.
U1. #
U1. #
Object-Oriented Methodology
The object-oriented systems analysis and design methodology classification emerged in the mid- to late 1980s as businesses began to seriously consider object-oriented-programming languages for developing and implementing systems. Even though Simula,, is credited as being the first object-oriented language, popular object-oriented (or object-enabled/enhanced) languages such as Smalltalk, C++, Objective C, and Eiffel came into their own in the 1980s and Java was introduced by Sun Microsystems in mid-1995. Rather than follow the structured, deterministic, and sequential programming paradigm associated with languages such as COBOL, Fortran, C, Basic, PL/I, Ada, Algol and others, these languages follow the approach pioneered by Simula based on objects, attributes, responsibilities, and messages.
U1. #
CHARACTERISTICS OF AN OBJECT-ORIENTED METHODOLOGY 1. Objects 2. classes 3. Abstraction 4. Encapsulation or information hiding 5. Inheritance 6. Polymorphism 7. Message communication 8. Associations 9. Reuse
U1. #
Analysis
Begin with the Statement of Requirements and then view the Use Cases. The Use Case document has a Use Case Diagram and a series of flows of events, one for each use case. The analysis phase can be studied both in terms of the "big picture" and in terms of the details of the use cases.
U1. #
U1. #
U1. #
U1. #
The Characteristics of ObjectOriented Design (OOD) The Use of Classes in OOD The use of Inheritance in OOD The Use of Polymorphism in OOD Creating a Class Diagram:
U1. #
Design process.
Having looked at the requirements/analysis documents, you can then study the design phase by viewing the CRC cards, the overall Class Diagram, and the Statechart and Interaction Diagrams. There is one CRC card for each class, incorporating all responsibilities of the class arising from all of the use cases, linked to from the icon for the class in either Class Diagram. The CRC cards were created by "walking through" each use case, assigning the responsibility for each task to some class. Note that there are CRC cards for classes that do not appear in the Analysis Class Diagram; the need for these classes became apparent as the other cards were being created.
U1. #
The Class Diagram pulls together all of the structural information from the CRC Cards and shows the needed links between classes. Each class icon is linked to other relevant design documents, including a detailed design for that class. For the major controller classes, there is also a Statechart diagram depicting the various states the corresponding object can be in. Finally, there is one Interaction diagram for each use case, linked to from the use case flow of events. This shows the objects that work together to realize the use case, and the flow of messages between them. The detailed design document was developed directly from the Interaction diagrams and Class Diagram.
U1. #
Responsibility-Driven Design Responsibility-Collaboration (CRC) Responsibility-Driven Collaboration (CRC) Design
(RDD)/Class-
(RDD)/Class-Responsibility-
In Responsibility-Driven Design, a model is developed from the requirements specification by the extraction of nouns and verbs from the specification. This provides a basis for the actual implementation. In RDD, for each class, different responsibilities are defined which specify the roles of the objects, and their actions. In order to fulfill these responsibilities, classes need to collaborate with each other. Collaborations are defined to show how the objects will interact. The responsibilities are further grouped into contracts which define a set of requests that objects of the class can support. These contracts are further refined into protocols, which show the specific signature of each operation.
Classes
- Extract noun phrases from the specification and build a list - - identify candidates for abstract super classes - use categories to look for missing classes - write a short statement for the purpose of each class
Responsibilities
- find responsibilities
- assign responsibilities to classes - find additional responsibilities by looking at the relationships between classes
Collaborations
- find and list collaborations by examining responsibilities associated with classes - identify additional collaborations by looking at relationships between classes - discard and classes that take part in no collaboration (as client or server)
U1. #
CRC Cards
CRC is useful in detecting responsibilities of objects are CRC cards (developed by Kent Beck and Ward Cunningham). CRC stands for Class-Responsibility-Collaborator. They look like:
U1. #
CRC Cards
Identify and clarify objects Understand behaviours for objects and what they must carry out Understand how object cooperate with one another CRC cards are index cards, one for each class, upon which the responsibilities and collaborators of a class are written. Each person holds onto the CRC cards for the classes that they are playing the role of.
U1. #
U1. #
CRC Cards
U1. #
CRC Cards
U1. #
CRC Cards
U1. #
Learning Objectives
OO Methodology
Rumbaugh OMT Booch OOD Jacobson OOSE ObjectOry Hierarchical Object Oriented Design (HOOD) Object Oriented System Design (OOSD) Object Oriented System Analysis (OOSA) Object Oriented Analysis (OOA)
U1. #
OMT Modeling OMT separates modeling into three different parts: An object model, presented by the object model and the data dictionary. A dynamic model, presented by the state diagrams and event flow diagrams. A functional model, presented by data flow and constraints.
Rumbaugh OMT Models

Static
Object model with attributes, operations and relationships (extension of E-R model)
Dynamic
State transition diagrams (network of states and events)
Functional
Based on classical DFD
U1. #
OMT Stages and Models

Object Model - Static structure of objects and their relationships (object diagram)
Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design - Algorithms/data structures to implement each class Implementation - Translation of object classes and relationships to a particular object-oriented language
Dynamic Model - Control aspects of the system (state diagrams)
Functional Model - Data value transformations (dataflow diagrams)
time
System
U1. #
Introduction to Object-Oriented Analysis

Object-Oriented Analysis is the requirements phase of ObjectOriented Software Development
technique
class modeling dynamic modeling functional modeling
Reuses familiar tools

E-R diagrams Finite State Machines Data flow diagrams
These steps focus on

data actions their relationships
Steps and diagrams

typically performed in parallel after initial class definition must be kept in synch
U1. #
Models of Object-Oriented Analysis (UML)

Class Model
static structure what objects are in the system? how are they related?
Data-Oriented
Dynamic Model
behavioral aspects what events occur in the system when do they occur and in what order?
Action-Oriented
Functional Model data transformations what does the system do
Both Data and Actions
U1. #
Classes, Attributes and Operations

Attributes define the properties of the objects
every instance of the class has the same attributes an attribute has a data type the values of the attributes may differ among instances
Operations define the behavior of the objects

action performed on or by an object available for all instances of the class need not be unique among classes
Class
ball football baseball
Attributes
radius, weight air pressure liveness
Operations
catch, throw pass, kick, hand-off hit, pitch, tag
U1. #
Object Model Notation

Classes are represented as rectangles;
Class Name
InstanceVariable1 InstanceVariable2: type
Method1() Method2(arguments) return type
The class name is at the top, followed by attributes (instance variables) and methods (operations)
Depending on context some information can be hidden such as types or method arguments
(Class Name)
InstanceVariable1 = value InstanceVariable2: type
Method1() Method2(arguments) return type
Objects are represented as rounded rectangles; The objects name is its classname surrounded by parentheses Instance variables can display the values that they have been assigned; pointer types will often point (not shown) to the object being referenced
U1. #
OMT Instantiation Notation

Class Name
Class
attribute_1: data_type_1 = default_1 attribute_2: data_type_2 = default_2 ... attribute_m: data_type_m = default_m
(Class Name)
Instance
attribute_1 = value_1 attribute_2 = value _2 ... attribute_m = value _m

U1. #
Instantiation - Example
Person
(Person)
name age weight
Joe Smith age=39 weight=158
(Person) Mary Wilson age=27 weight=121
U1. #
Inheritance
Classes with similar attributes and operations may be organized hierarchically Common attributes and operations are factored out and assigned to a broad superclass (generalization)
generalization is the is-a relationship superclasses are ancestors, subclasses are descendants
Classes iteratively refined into subclasses that inherit the attributes and operations of the superclass (specialization)
U1. #
OMT Inheritance Notation

Generalization
Superclass
Class Attributes Operations Ball Radius, Weight Throw, Catch
Subclasses Football air pressure pass, kick, hand-off Baseball liveness hit, pitch, tag Basketball air pressure , dimples shoot, dribble, pass
Specialization
Association and Links

An association is a relation among two or more classes describing a group of links, with common structure and semantics A link is a relationship or connection between objects and is an instance of an association A link or association is inherently bi-directional
the name may imply a direction, but it can usually be inverted the diagram is usually drawn to read the link or association from left to right or top to bottom
A role is one end of an association

roles may have names
OMT Association Notation

Class, Association, and Roles
Person Works For equivalent Company
Company
Employs
Employer Employee
Person
Object and Link

(Person) Works For (Company) IBM
U1. #
Johnson
Association and Links

Country name has-capital City Class diagram name
(Country) Canada (Country) France
has-capital
(City) Ottawa
has-capital
(City) Paris Instance diagram
(Country)
Austria
has-capital
(City)
Vienna
U1. #
Aggregation
Aggregation is a special form of association that indicates a part-of relationship between a whole and its parts Useful when the parts do not have independent existence
A part is subordinate to the whole
In an aggregation, properties and operations may be propagated from the whole to its parts
U1. #
OMT Aggregation Notation
Window
TitleBar
ScrollBar
Border
U1. #
Multilevel aggregation
Microcomputer
1+
Monitor
System box
Mouse
Keyboard
1+
1+
Chassis
CPU
RAM
Fan
U1. #
Overview - Object-OrientedAnalysis and Design

Three models
Object model Dynamic model Functional model
U1. #
States and Transitions

A state is an interval between events (values of relevant variables to the problem)
it may have an activity that can trigger starting, intermediate and ending events defined in terms of a subset of object attributes and links
A state transition is a change in an objects attributes and links

it is the response of an object to an event all transitions leaving a state must correspond to distinct events
U1. #
OMT State Notation

states represented as nodes: rounded rectangles with state name
initial state represented as solid circle final state represented as bulls eye
transitions represented as edges between nodes and labeled with an event name
Event-b STATE-1 Event-a Event-c STATE-3 Event-e Event-d result STATE-2
U1. #
OMT State Diagram - Example

Chess game
Start
Whites turn
black moves white moves
checkmate
Black wins
stalemate
Draw stalemate
Blacks turn
White wins checkmate
U1. #
Guards, Activities and Actions

Guards are boolean conditions on attribute values
transition can only happen when guard evaluates to true automatic transitions occur as soon as an activity is complete (check guard!)
Activities take time to complete

activities take place within a state
Actions are relatively instantaneous

actions take place on a transition or within a state (entry, exit, event actions) output can occur with an event
A-STATE entry / entry-action do: activity-A event-1 / action-1 ... exit / exit-action [guard-1]
STATE-1
action-Event / action output-Event / output
guarded-Event [guard-2]
STATE-2
U1. #
OMT State Relationships

States can be nested or concurrent Events can be split and merged
event-1
Superstate (nesting)
event-1
Superstate (concurrency)
substate-1 substate-3
substate-1
substate-2
event-2
event-3
substate-2
substate-4
event-2
(Synchronization)
split-event-0
substate-1
event-1
substate-3
merged-event-3
substate-2
event-2
substate-4
merged-event-4
U1. #
State Generalization: example

Transmission
push N
Neutral
push R
Reverse
push N
push F
Forward
stop
upshift
upshift
First
downshift
Second
downshift
Third
U1. #
Functional Modeling
Identify input and output values Build data flow diagrams showing transformation and functional dependencies Describe functions (in some language)
U1. #
Booch OOD
Aimed on physical design and programming rather than requirement and conceptual design Describes two levels of diagram Design level
Class, object, state transition and interaction diagrams

Implementation level
Module and process diagrams
U1. #
Booch OOD
Suggest two development process
Micro Development Process Represents the daily activities of the individual developer
Macro Development Process Serves as the controlling framework for the micro process
U1. #
Jacobson OOSE
Originated from Objectory (Object Factory for software development) Aim to fit the development of large real-time system Covers entire life cycle Stress traceability among the different phases (Backward & forward) Usecase concept is core
U1. #
Object Oriented Methods ObjectOry
Developed by Jacobson. Supports OO concepts of classification, encapsulation and inheritance. Abstraction is promoted by levels. Adds use cases to the OO approach. Composite data and activity definition is not strongly enforced and services are also regarded as objects. Reuse is supported by component libraries. Guidance for analysis is less comprehensive. Target applications: like HOOD real-time systems and engineering systems.
U1. #
Objectory
Discipline process for the industrialized development of software, based on a usecase driven design Built around several different models Requirement Model Domain object model Analysis Model Design Model Implementation model Test model
U1. #
Object Oriented Business Engineering

Object modeling at the enterprise level Use case central vehicle for modeling Marjory three phases
Analysis Design and implementation Testing
U1. #
OOSE
Object-oriented software engineering (OOSE) is an object modeling language and methodology. Object-Oriented Software Engineering (OOSE) is a software design technique that is used in software design in object-oriented programming. OOSE is developed by Ivar Jacobson in 1992. OOSE is the first objectoriented design methodology that employs use cases in software design. OOSE is one of the precursors of the Unified Modeling Language (UML), such as Booch and OMT. It includes a requirements, an analysis, a design, an implementation and a testing model. Interaction diagrams are similar to UML's sequence diagrams. State transition diagrams are like UML statechart diagrams.
U1. #
Figure 1. Object-Oriented Software Engineering.
U1. #
Figure 2. Jacobsons Use Case diagram.
U1. #
U1. #
HOOD, Hierarchical Object Oriented Design

HOOD, Hierarchical Object Oriented Design, is emerging as the main European object-oriented design methodology. The European Space Agency developed HOOD, and toolkits have been produced by several major software companies. This reference on HOOD covers the following areas: HOOD method; finding objects and operations; HOOD diagrams; object description skeleton; class and instance objects; real time design; and distributed software design. There is a strong emphasis on the engineering aspects of developing software in a multi-team environment. Most chapters are illustrated by examples and the book should find a wide readership amongst professional software engineers.
U1. #
HOOD (Hierarchic Object-Oriented Design) is a detailed software design method. It is based on hierarchical decomposition of a software problem. It comprises textual and graphical representations of the design. HOOD main target languages are Ada, Fortran and C. An architectural design method, primarily for Ada, leading to automated checking, documentation and source code generation.
U1. #
Object Oriented Role Analysis, Synthesis and Structuring (OORASS), the method focuses on describing patterns of interaction without connecting the interaction to particular objects/instances.
U1. #
Why O-O Model?

Possible to directly represent real world objects in the computer system Thus, solves the so-called impedance mismatch problem.
Data-oriented model
Object-oriented model
Real world
Software system
Real world
Software system
190
Object-oriented Design
Goal : to design classes identified during analysis phase & user interface Identify additional objects & classes that support implementation of requirements
Eg. add objects for user interface to system (data entry windows, browse windows)
Can be intertwined with analysis phase

Highly incremental, eg. can start with object-oriented analysis, model it, create object-oriented design, then do some more of each again & again, gradually refining & completing models of system Activities & focus of oo analysis & oo design are intertwined, grown not built
U1. #
Object-Oriented Analysis and Design

Design thinking Object Modeling Technique
Object-Oriented Analysis Object-Oriented Design
Three models
Object model Dynamic model Functional model
U1. #
Design Goals
Design transforms requirements into
an architecture diagram
subsystems, modules and their relationships
a detailed design
a specification of the abstract interface, data structures, and algorithms of each module
Also develops
a review plan for ensuring the design meets the requirements a test plan for ensuring the implementation meets the design
U1. #
Analysis Methods
Functional Decomposition = Functions + Interfaces Data Flow Approach = Data Flow + Bubbles Information Modeling = Entities + Attributes + Relationships Object-Oriented = Objects + Inheritance + Message passing
U1. #
Object Oriented Methods Hierarchical Object-Oriented Design (HOOD)

Scores well on OO properties. Encourages modeling of objects explicitly. Objects are modeled in a hierarchical manner. Strong emphasis on the object interface specification and encapsulation. The OO model of systems is supported. Overall, incorporates many OO properties. Uses Boochs concepts (actors and servers) Supports object classes, but inheritance and reuse are not made explicit. Real time-method -> data specification and associated inheritance receive less attention.
U1. #
Object Oriented Methods Object-Oriented Systems Design (OOSD)

Assumes analysis phase has been completed. Provides detailed notation for object classes and management of inheritance. Inter-object communications (event/message types) Detailed notation for interface description and encapsulation. No analysis advice is given.
U1. #
Object-Oriented Systems Design (OOSD) Object Model Structure Chart
U1. #
Object Oriented Methods Object-Oriented Systems Analysis (OOSA)
Many heuristics for object identification and analysis, which help with initial abstraction and object modeling. Data modeling approach (ER modeling) Models an object relationship network with subclasses. State-transition specifications are constructed for each object and functions are modeled with data-flow diagrams. Produces a composite activity-data model (synthesis not clearly specified) Lack of support for inheritance. Underspecified in the design phase.
U1. #
Object-Oriented Systems Analysis (OOSA) Object Relationship Model
U1. #
Object Oriented Methods Object-Oriented Analysis (OOA)

Covers all OO concepts, although analysis method only. Classification and inheritance are modeled and abstraction is helped by the structure layer (Subject, Structure, Attribute, Service) Uses hierarchical inheritance. Specification of encapsulation and object interfaces is not as detailed as OOSD, or HOOD. Overall, it does meet many OO criteria.
U1. #
Object-Oriented Software Development

Object-Oriented Methodology
development approach used to build complex systems using the concepts of object, class, polymorphism, and inheritance with a view towards reusability encourages software engineers to think of the problem in terms of the application domain early and apply a consistent approach throughout the entire life-cycle
Object-Oriented Analysis and Design

analysis models the real-world requirements, independent of the implementation environment design applies object-oriented concepts to develop and communicate the architecture and details of how to meet requirements
U1. #
Build and Fix Model

Problems No specifications No design Totally unsatisfactory Need life-cycle model Game plan Phases Milestones
U1. #
Waterfall Model
Characterized by Feedback loops Documentation-driven Advantages Documentation Maintenance easier Disadvantages Specifications
U1. #
Prototyping Model
Linear model Rapid
U1. #
Incremental Model
Divide project into builds
U1. #
Incremental Model Cont..

Waterfall, rapid prototyping models Operational quality complete product at end Incremental model Operational quality portion of product within weeks
Smaller capital outlay, rapid return on investment

Need open architecturemaintenance implications Variations used in object-oriented life cycle
U1. #
De te r mine o bjec t ives, alt erna t ives, & c on st r ain ts

Risk a na l y sis Risk a na l y sis Risk a na l y sis P1
Evalu at e alt erna t ives, ide nt if y & reso lv e risk s
Pr o t o ty p e3 Pr o t o ty p e2 Pr o t o ty p e1 Re q uire m e nts pl an Co n ce pt of o pe ra ti on
Sof twar e Re q uire m e nts
Sy st em Pr o du ct De si gn
De ve lop m e nt Re q uire m e nts pl a n v alida t io n
De tailed De si gn
P2
Co d e Un it T e st
Pla n ne xt ph ase
I nte gr ation pl an
De si gn v alida t io n Ac ce pta nc e T e st
Develo p & v er if y ne xt le vel prod uc t
I nte gr ation &Te st
Spiral Model
Life Cycle Model of OOSAD

Domain
O O A
Application Scenario
Identify Actors Identify Classes Build Interface Objects Build Detail Design
Identify Use cases Identify Objects Build Dynamic Model Use Tools & Program for Implementation
Build Use Case Model Examine Reusable Objects
Do Object Analysis Test Build OO System Design
O O D
Build Prototype
Test Usage Scenario (Use Case) Test for QA Acceptance Post Implementation Hand Over
U1. #
O O I
Constitute of a Rational Enterprise Philosophy
Support process
for
architecture,
method
or
Tools
How to scale up the method to industry activity
Process Method Architecture

How to apply the architecture concept(step by step) The selected approach from a universe of approaches (Foundation of concepts and technology)
U1. #
Constituents of Multiple Activities of a Rational Enterprise
Tools Process Method Architecture
Tools
Tools Process Method Architecture
Process
Method Architecture
Creative Design
Construction
Long Term Support
U1. #
Software Industry Direct Analogies with Rational Enterprise Process must yield a foreseeable result, irrespective of which individual performed the job Volume of output doesnt effect the process Possibility to allocate parts of the process to several manufacturers/subcontractors Possible to make use of predefined building blocks and components Possible to plan and calculate the process with great precision. Each person trained for an operation must perform it in a similar manner
System Development Characteristics

Part of a large activity System Development Transition from Analysis to Construction Requirements are input to system development A system is output system development Parties interested in system development are customer, comp. dept., direct users, indirect users`
U1. #
Reasons Projects Fail

Project Challenged Factors % of Responses 1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications
12.3%
3. Changing Requirements & Specifications
11.8%
4. Lack of Executive Support
7.5%
5. Technology Incompetence
7.0%
6. Lack of Resources
6.4%
7. Unrealistic Expectations
5.9%
8. Unclear Objectives
5.3%
9. Unrealistic Time Frames
4.3%
10. New Technology
3.7%
Other
23.0%
U1. #
Reasons Projects Succeed

Project Success Factors % of Responses 1. User Involvement 2. Executive Management Support 3. Clear Statement of Requirements 4. Proper Planning 5. Realistic Expectations 6. Smaller Project Milestones 7. Competent Staff 8. Ownership 9. Clear Vision & Objectives 10. Hard-Working, Focused Staff Other 15.9 13.9 13.0 9.6 8.2 7.7 7.2 5.3 2.9 2.4 13.9
U1. #
U1. #
U1. #
U1. #
U1. #
U1. #
U1. #
RequisitePro
RequisitePro
is a powerful management automation tool.
requirement
Offers the power of database and word.

Comprises of document templates.
Integration with Rational ClearCase, Rational SoDA.
Rose,
Rational
In-built email facility with ReqWeb utility.
U1. #
Objective Questions
Q1. Define the following terms: Object Class Attribute Method Message State Encapsulation Data Abstraction Data Hiding Inheritance Polymorphism Strong and weak typing Overriding Object persistence Containership Generacity
U1. #
Objective Questions..
Q2. Which of the following statements are true?
1. According to Rebecca Wirfs-Brock, a stereotype is a high-level classification of an object such as "controller" and "coordinator". 2. According to Jacobson, class stereotypes are: interface object, control object and entity object. 3. Within UML, stereotypes are used for meta-model extensions. 4. All of the above. 5. None of the above.
Q3. Estimate what percentage of your effort and time you spend on Inception, Elaboration, Construction and Transition phases.
U1. #
Short Questions
Q1. Compare object oriented software engineering and classical software engineering. Q2. what is a CRC card? How it helps in the development of Object Oriented System? Q3. Why should begin with the object oriented analysis and object oriented design Q4. Explain why object-oriented programs are said to be more maintainable and reusable as compare to function-oriented programs? Q5. How you will support the object-oriented paradigm over the structure paradigm for software engineering discipline. Q6. What are the requirement elicitation major activities, techniques used and the key deliverables of these activities? Describe Focus Ethnography in short. Q7. Describe the development process with model building Q8. Discuss in short Requirement Change Process Q9. How you represent a class in CRC? Q10. Write short note on constitute of a rational enterprise philosophy.
Long Questions
Q1. What is requirement elicitation? Explain two techniques of requirement elicitation. Q2. What is a use case? How it is beneficial in requirement phase? Is there any other way to capture requirements? Q3. Which requirement elicitation is most popular? Explain. Q4. Explain object oriented life cycle model. Give a brief comparison of various life cycle models. Q5. Compare and contrast various software development models in tabular form. State the advantage and disadvantage of each model. Q6. List out Requirements Elicitation Techniques. Which one is most popular and why? Q7. Discuss the object oriented software development life cycle. Q8. Discuss different aspects of Booch's methodology for object oriented design. Q9. How Object Model, Dynamic Model and Functional Model are related to each other? Q10. Compare and contrast waterfall, spiral and fountain model. List their advantages and disadvantages. Q11. Compare and contrast various requirement elicitation methods. Q12. Discuss the role of use-cases in object oriented requirement analysis? Q13. In what way does the object oriented approach claim to improve the system development process Q14. List down the top ten risks of conventional processes address by modern objectoriented Process with solution.
Long Questions..
Q15. List few object languages and compare them Q16. Survey of Software Life Cycle Model with Comparison Chart and elaborate your viewpoint what sequence of activities can be used in general to develop a software in an IT organization. Q17. What are the various software development activities? Draw the object model of the software life cycle. Explain Iterative and prototype model. Q18. What are the constitute of rational enterprise constitute philosophy discuss in short Describe various System development characteristics Q19. Discuss the software development best practices. Q20. Discuss various System Development Characteristics Q21. What factors can be blamed for software failure (over budget, delayed in schedule and fail to meet expectation) and how could the failure have been avoided? Describe Q22. Provide the use case model for software development process. Discuss OOSAD lifecycle model. What are the potential benefits and drawback of it? Q23. Discuss the object oriented systems metrics Suggested by Chidamber and Kemerer.
U1. #
References
Ivar Jacobson, Object Oriented Software Engineering, Pearson, 2004. Grady Booch, James Runbaugh, Ivar Jacobson, The UML User Guide, Pearson, 2004 3. R. Fairley, Software Engineering Concepts, Tata McGraw Hill, 1997. 4. P. Jalote, An Integrated approach to Software Engineering, Narosa, 1991. 5. Stephen R. Schach, Classical & Object Oriented Software Engineering, IRWIN, 1996. 6. James Peter, W Pedrycz, Software Engineering, John Wiley & Sons 7. Sommerville, Software Engineering, Addison Wesley, 1999. 8. http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon_u sers_guide/userguide.html 9. http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon_u sers_guide/statemachinediagram.html 10. http://www.developer.com/design/article.php/2238131/State-Diagram-inUML.htm 1. 2.
11. http://www.mariosalexandrou.com/methodologies/extre me-programming.asp


Ooad Unit I

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ooad Unit I

Caricato da

Copyright:

Formati disponibili

OBJECT-ORIENTED ANALYSIS AND DESIGN

Class Diagram of Employee class

Functions: Setbp( ) Totsal( ) Deductions( )

Application Areas of OOPS

Merits of object approach

The Object Model

Transition From Analysis to Design

Objects enter here

What to do during OOA?

OOA(By Coad)- Method

The Unified Approach (UA)

Classification is used to group entities that share common characteristics

Class Attributes (Contd)

Class Attributes (Contd)

<<entity>> instructor Professor 0..1

<<entity>> CourseOffering 0..* 0.. *

1-to-1 and 1-to-many Associations

x: Integer y: Integer z: Integer

Association Relationships (Contd)

Association Relationships (Contd)

teaches Student 1..*

learns from 1..* Instructor

Association Relationships (Contd)

membership Student 1..* 1..* Team

member of 1..* Student

Generalisation and inheritance

Ma nager budgetsControlled dateAppointed

Programmer project progLanguage

Project Ma nag er projects

De pt. Ma nager dept

Strategic Ma nag er responsibilities

Battery amps volts

diameter number of bolts

Inheritance relates classes (a way to structure the description of a single object)

Employee class (UML)

Representing Classes in the UML

Representing Objects in the UML

UML: Class and Instance Diagrams

Attributes and Values

joe:Inspector name = Joe age = 24

name = Mary age = 18

Object Oriented Methodologies

Responsibility-Driven Design Responsibility-Collaboration (CRC) Responsibility-Driven Collaboration (CRC) Design

Rumbaugh OMT Models

OMT Stages and Models

Dynamic Model - Control aspects of the system (state diagrams)

Functional Model - Data value transformations (dataflow diagrams)

Introduction to Object-Oriented Analysis

Reuses familiar tools

These steps focus on

Steps and diagrams

Models of Object-Oriented Analysis (UML)

Functional Model data transformations what does the system do

Both Data and Actions

Classes, Attributes and Operations

Operations define the behavior of the objects

Object Model Notation

OMT Instantiation Notation

attribute_1 = value_1 attribute_2 = value _2 ... attribute_m = value _m

name age weight

Joe Smith age=39 weight=158

(Person) Mary Wilson age=27 weight=121

OMT Inheritance Notation