OO Design

BITS PilaniPilani Campus

Object Oriented Analysis & Design

K Hari BabuDepartment of Computer Science & Information Systems

Dept. of Computer Science & Information Systems BITS Pilani, Pilani Campus

Traditional Software Development Model

• Algorithms + Data Structures = Programs• Emphasis was more on functionality.• In object oriented systems, emphasis is on objects

which combine functionality and data together.• Tell system: “Compute payroll of this employee.”• Tell employee object: “Compute your payroll”

– Responsibilities are assigned to objects.


Software development

• Analysis, design, implementation, testing & refinement to transform users’ need into software solution that satisfies those needs

• Object-oriented approach – more rigorous process to do things right– more time spent on gathering requirements,

developing requirements model & analysis model, then turn into design model

– need not see code until after 25% development time


Software process – transforming needs to software product


Object-oriented approach: A use-case driven approach• Object-oriented software development life cycle consists

of– Object-oriented analysis– Object-oriented design– Object-oriented implementation

• Use-case model can be employed throughout most activities of software development– designs traceable across requirements, analysis, design,

implementation & testing can be produced– all design decisions can be traced back directly to user

requirements– usage scenarios can be test scenarios


Object-Oriented Systems Development Approach


Object-Oriented software development

• Activities • Object-oriented analysis - use case driven• Object-oriented design• Prototyping• Component-based development• Incremental testing

• Encourages– viewing of system as a system of cooperative objects– incremental development


Object-oriented analysis - use-case driven• Use Case, is a name for a scenario to describe

the user–computer system interaction. • Determine system requirements, identify classes

& their relationship to other classes in domain• To understand system requirements

– need to identify the users or actors• who are the actors ? How do they use system ?


Use case• Typical interaction between user & system

that captures users’ goal & needs• use cased modeling

– expressing high level processes & interactions with customers in a scenario & analyzing it

– gives system uses, system responsibilities• developing use case is iterative

– when use case model better understood & developed, start identifying classes & create their relationship


Identifying objects

• What are physical objects in system ?– Individuals, organizations, machines, units of

information, pictures, whatever makes up application/ make sense in context of real world

– objects help establish workable system

• Intangible objects ?– Data entry screens, data structures

• Documentation– modeling & documentation inseparatable

• good modeling implies good documentation


Object-oriented Design

• Goal : to design classes identified during analysis phase and the user interface

• Identify additional objects & classes that support implementation of requirements– Eg. add objects for user interface to system (data

entry windows, browse windows)

• Activities & focus of oo analysis & oo design are intertwined


Object-oriented Design

• First, build object model based on objects & relationship

• Then iterate & refine model– Design & refine classes– Design & refine attributes– Design & refine methods– Design & refine structures– Design & refine associations


Guidelines in Object-oriented Design

• Reuse rather than build new classes– Know existing classes

• Design large number of simple classes rather than small number of complex classes

• Design methods• Critique what has been proposed

– Go back & refine classes


Model• Model is an iterative process.• It can represent static or dynamic

situations.• Model

Static Dynamic

Represents a system’s behaviors that, taken together, reflect its behavior over time.

(e.g.) interaction & activity diagrams

Provides a system’s parameters at rest or at a specific point in time.

(e.g.) class diagram


Why modeling

• Blue print• Clarity• Familiarity • Maintenance• Simplification


Advantages of modeling

• Easy to express complex ideas• Reduce complexity• Enhance & reinforce learning and training• Low cost• Easy to change the model


What is Unified Modeling Language (UML)?

• The UML is a graphical / standard language for visualizing, specifying, constructing & documenting the artifacts of a software system.


History of UML• 1980 – 1990 Many different methodologies

1. Booch method by Grady Booch2. Object Modeling Technique (OMT) by Jim

Rumbaugh3. Object Oriented Software Engineering (OOSE) by

Ivar Jacobson

• Each method had its strengths & weaknesses. 1. Booch was great in design2. OMT & OOSE were great in analysis


History of UML

UML 1.0 (January 1997)

UML 1.1 (November 1997)

UML 1.3 (Minor revision 1999)

UML 1.4 (Minor revision 2000)

UML 2.0 (Major revision 2004)


UML Concepts

• UML can be used to support entire software life cycle.

1. The interaction of application with the outside world (use case diagram)

2. Visualize object interaction (sequence & collaboration diagrams)

3. The structure of system (class diagram)4. View the system architecture by looking at the defined

package.5. The components in your system (component diagram)


UML Diagrams

1. Class diagram (Object Modeling)2. Use case diagram3. Activity diagram4. Sequence diagram5. Collaboration diagram6. State chart diagram7. Component diagram8. Deployment diagram


1. Class diagram Shows tatis structure of the system Object modelling is the process by which the logical

objects in the real world are mapped to objects in the program.

Problem space logical space


2.Use case diagram

• It shows a set of use cases and actors and their relationships.

• Address the static view of a system.• Actor user (or) someone / something

outside the system that interacts with the system (it must be a noun) & it is represented by a stickman.

……contd


2.Use case diagram

• Use case a sequences of actions (it must be a verb) & it is represented by an oval.

• Relationship illustrates a connection among model elements.

Unidirectional Bi-

directional • It is created to visualize the interaction of your

system with the outside world.


2.Use case diagram


3.Activity Diagram

• It shows the flow of events with our system & what is going on inside a use case.

• We draw the activity diagram for each & every use case.

• It is showing flow of control from activity to activity.


3.Activity Diagram

• Activity it represents the performance of a task within the workflow.

• Activity is represented by a lozenge (horizontal top and bottom with convex sides)

• Start state shows the beginning of a workflow on an activity diagram.

• There is only one start state.


3.Activity Diagram

• A start state is represented by a solid circle.

• An end state represents a final or terminal state on an activity diagram.

• A end state is represented by a bull’s eye.


3.Activity Diagram

• A state transition shows what activity follows after another.

• It is represented by a solid line with an arrow.


3.Activity Diagram

• A decision is a point in an activity diagram where guard conditions are used to indicate different possible transitions.

• It is represented by a diamond.• Guard conditions control the transition of a set of

alternate transitions that follows after the activity has been completed.


3.Activity Diagram

AND

Joint

Synchronization bar


3.Activity Diagram

• A synchronization bar allows you to show concurrent threads in a work flow of a use case.

• It represented by a thick horizontal or vertical line.


3.Activity Diagram – ProcessLoan Use case


4.Sequence Diagram

• It shows step by step what must happen to accomplish a piece of functionality provided by the system.

• It has 2Ds.1. Vertical dimensions represents time2. Horizontal dimensions represents

different objects.• Vertical line is called the object’s life line.


4.Sequence Diagram

• Life line the existence object at a particular time.

• Objects are shown at the top.

• The object role is shown as a vertical dashed line, the life line.


4.Sequence Diagram

• A message is the communication between 2 objects that triggers an event.

• It is represented by a labeled arrow.

• Each message is represented by an arrow between the life lines of 2 objects.


4.Sequence Diagram

• A focus of control shows the period of time during which an object is performing an action, either directly or through a subordinate procedure.

• It represented by a tall, thin rectangle.


4.Sequence Diagram


5.Collaboration Diagram

• It displays objects and their links to one other.


5.Collaboration Diagram• It is made up of the following basic

elements :1. Actors2. Objects3. Links4. Messages


5.Collaboration Diagram1. Actors user 2. Objects data + logic / the representation of some real world entity.3. Links a pathway for communication between objects.

represented by a solid line between 2 objects4. Messages the communication between objects that triggers an event. represented by a labeled arrow above the link.


5.Collaboration Diagram


6. State Chart Diagram

• It shows the sequence of states.• A state is represented as a rounded box,

which may contain one or more compartments.

• Name compartment holds the name of the state.

• Internal transition compartment list of actions / activities

• Start & end states


6. State Chart Diagram


7.Component Diagram

• It shows relationship between the components in the system.

• A component may be a software component [for (e.g.) a.h file in C++ (or) a .java file in Java], a run time component [for (e.g.) a.DLL file]


7.Component Diagram


8. Deployment Diagram

• It shows the configuration of run time processing elements & the software components, processes & objects that live in them.

• It shows the nodes in the system & the connections between them.


8. Deployment Diagram


Object Oriented Analysis

• Identifying Use Cases• Object Analysis: Classification• Identifying object relationships, Attributes

and Methods.


Identifying the use cases: Goals

• The use-case approach to object-oriented analysis and the object-oriented analysis process.

• Identifying actors.• Identifying use cases.• Documentation.


Sources

• 1. Examination of existing system documentation.

• 2. Interviews. • 3. Questionnaire. • 4. Observation.


The Object-Oriented Analysis (OOA) Process• The process consists of the following

steps: • 1. Identify the actors:

– Who is using the system? – Or, in the case of a new system, who will be

using system?


The OOA Process

• 2. Develop a simple business process model using UML activity diagram.


The OOA Process

• 3. Develop the use case: – What the users are doing with the system? – Or, in the case of a new system, what

users will be doing with the system?


The OOA Process (Con’t)

• 4. Prepare interaction diagrams: – Determine the sequence. – Develop collaboration diagrams.


The OOA Process (Con’t)

• 5. Classification—develop a static UML class diagram:– Identify classes.– Identify relationships.– Identify attributes.– Identify methods.


The OOA Process (Con’t)• 6. Iterate and refine: If needed, repeat

the preceding steps.


Use Case Model

• Use cases are scenarios for understanding system requirements.

• The use-case model describes the uses of the system and shows the courses of events that can be performed.

• Some Definitions– User – Human Users + Other Systems– Use Case – A piece of functionality– Use-Case Model – All the use cases– Use-Case Driven – Development

process follows a flow


Use Case Model (Con’t)

• Use case defines what happens in the system when a use case is performed.

• The use-case model tries to systematically identify uses of the system and therefore the system's responsibilities.


Use Cases

• "A Use Case is a sequence of transactions in a system whose task is to yield results of measurable value to an individual actor of the system."


<<uses>> Associations

• The <<uses>> association occurs when you are describing your use cases and notice that some of them have common subflows.

• The <<uses>> association allows you to extract the common subflow and make it a use case of its own.


Extends Associations

• The <<extends>> association is used when you have one use case that is similar to another use case but does a bit more or

• Is more specialized; in essence, it is like a subclass.


Use Case Diagram NotationActor

Association

Use Case

Use case with Extension points

<<Uses>>

<<Extends>>


Capture the system's functional requirements from the users' perspective

Actively involve users in the requirements-gathering process

Provide the basis for identifying major classes and their relationships

Serve as the foundation for developing system test cases

Purpose of Use-case Modeling


Case Study


Student welfare division oversees services students need. Students give their preference for hostel rooms, SWD assigns rooms. SWD issues certificates upon student’s request for common proofs such as bonafide certificate, residence certificate etc. Students need to register into courses at the beginning of every semester after consulting registration advisor. Registration in some courses require that prerequisite courses were cleared by student. Registration in some courses called ‘Audit Courses’ require a separate fee payment with the Institute cashier. Within two weeks from the registration day, students can substitute existing courses/add a new course. They will be verified and approved by dean of ARC. After 10 weeks from the day of registration, students may request withdrawal from courses. ARC staff supply course lists to faculty who teach courses. Faculty need to take attendance, conduct tests and assign grades.

Case Study

USE CASE NAME Request Certificate ACTOR Student DESCRIPTION Describes the process when a student submits a request for a certificate. NORMAL COURSE 1. Student enters idno and password in SWD website.

2. I f they match, he is displayed a menu. 3. Student navigates to request certificate page. 4. He selects the required certificate and submits. 5. Student logout. 6. Clerk of SWD login. 7. Clerk checks the validity of details. 8. Clerk drafts the certificate 9. Clerk prints the certificate. 10. Clerk gets the certificate signed by Dean, SWD. 11. Clerk keeps the certificate to dispatch window.

ALTERNATE COURSE 2. I f the idno and password is wrong, login screen is displayed again. 3. I f the student doesn't find the required certificate in the list, he personally approaches SWD

clerk. 7.

a) I f the student is invalid, clerk cancels the request with appropriate message. b) I f the certificate doesn't suit the student, clerk cancels the request. c) if clerk needs more details, he calls for the student.

PRECONDITION POST CONDITION Certificate is issued. ASSUMPTIONS


• Noun-Phrase Approach• Common Class Patterns Approach• Classes, Responsibilities, and Collaborators (CRC)

approach• Use Case driven approach

Identifying Classes


• Generally nouns give clues about classes, verbs give clue about methods.

1. Change plurals to singular and list all nouns.2. Make them into 3 categories.

1. Relevant classes2. Fuzzy classes3. Irrelevant classes (strike them off)

3. Review redundant classes.4. Review classes containing adjectives.

If adjective suggests a new behaviour, make a new class.

5. Review the possible attributes.They are used only as values

6. Review the class purpose.Each class must have a purpose. If we are not able to write a statement of purpose, eliminate it.

Noun-Phrase Approach


• Events:• Classes that are points in time that must be recorded. Attributes are who, what,

when, where, how, or why.

• Organization:• Classes that specify collection of people, resources, facilties … whose existence

is independent of individuals.

• People:• Those who interact with the system• People about whom information should be kept.

• Places:• Classes that represent physical locations, buildings, stores, sites …

Common Class Patterns Approach


• Based on the idea that an object either can accomplish a certain responsibility itself, or it may require the assistance of other objects.

Classes, Responsibilities, Collaborators (CRC Cards)


For each discovered class,1. Identify classes responsibilities2. Assign responsibilities3. Identify collaborators.

CRC Cards

Student

Name Room

RequestRoom Course

RegisterCourse

WithdrawCourseCollaborators


Three relationships are common among classes:• Dependency (“uses”)• Aggregation (“has”)• Inheritance (“is”)

Class Relationships


Three relationships are common among classes:• Association

• Physical or conceptual connection between two or more objects

• Dependency (“uses”)• Special case of association• A class depends on another class if it manipulates objects of the other class in any way.• Design goal: minimize dependencies.

• Aggregation (“has”)• Special case of dependency.• A class aggregates another if its objects contain objects of the other class.• “has-a” relationship.• Multiplicities *, 1..*, 0..1, 1• Composition: The contained object doesn’t have independent existence.

• Inheritance (“is”)• Capable of exhibiting the same behavior but possibly with additional responsibilities and richer state. • “is-a” relationship.

Class Relationships


Sequence Diagram

Source:ccs.neu.edu


Collaboration Diagram

Source:ccs.neu.edu


• A state diagram shows the states of an object and the transitions between states.

• Objects having discrete states that affect their beaviour.

State Diagram

Source: http://www.agilemodeling.com

OO Design

Documents

Transcript of OO Design