Y2 eProjects Session 4 – Advanced Topics. Objectives Dynamic Models Design Patterns (Optional) Software testing (for S4) ACCP i7.1\Sem3_4\eProject\T4.

Y2 eProjects

Session 4 – Advanced Topics

ACCP i7.1\Sem3_4\eProject\T4

Objectives

Dynamic Models Design Patterns (Optional) Software testing (for S4)

2

ACCP i7.1\Sem3_4\eProject\T4

Dynamic Models

Dynamic Models

Use Cases

State Machine

Sequence Diagram

Collaboration Diagram

Message and Message Notations Message is drawn as a line with an arrow between

sender and receiver of the message. The arrowhead indicates the type of the message sent

OOAD with UML / Session 7 / 4 of 25

State Diagram

OOAD with UML / Session 7 / 5 of 25

State diagrams are one set of diagrams which helps to draw the dynamics of a system

The state of an object at any point in time is the condition of the object at that instant

State of the object is defined by all the attributes of the object and the links maintained by it

State and Transition

The process of change in state is called state transition

Transitions are typically the result of the invocation of an operation that causes an important change in state

An action is something, in the case of a class it is an operation, which is invoked by/on the entity being modeled

Sub-state vs. composite state

The state of an object can have sub-states in it

A sub state is a part of the composite state Sub States can be concurrent or sequential

OOAD with UML / Session 7 / 7 of 25

OOAD with UML / Session 7 / 8 of 25

Sub-state vs. composite state (cont’d)

State diagram example

OOAD with UML / Session 7 / 9 of 25

Sequence Diagram

time

objects

A sequence diagram represents interactions between objects over the time

Recursion

Repetition of the same activity again and again until a condition is met

While showing recursion the event arrow comes back to the same object from where it started

OOAD with UML / Session 7 / 11 of 25

Collaboration Diagrams

Collaboration Diagrams describes object interaction with primary focus on events not the order of interactions ( as in Sequence Diagrams)

Objects are shown using the Class icon Sequence in Collaboration Diagram is shown by

numbering the messages Collaboration Diagrams are useful for

understanding all the effects on a given object and for procedural design

Collaboration Diagram example

Usage of dynamic models

Use Sequence and\or Collaboration Diagrams: For clarifying object behaviors within a single use

case Showing collaborations among the objects

Use state diagrams to look at the behavior object across use cases

For multi-threading, use activity diagrams

ACCP i7.1\Sem3_4\eProject\T4

Design Patterns (Optional)

Design Patterns are common ways of structuring programs typically deal with a small number of classes, but

can be of any size provide a communication framework in which

ideas can be discussed at a high level can specify how objects are created, how they

interact, or how they are structured

What are design patterns?

They are common ways of structuring programs typically deal with a small number of classes, but can

be of any size provide a communication framework in which ideas

can be discussed at a high level can specify how objects are created, how they interact,

or how they are structured Why Patterns?

Reuse solutions Vocabulary for development Better software

Design Pattern Example Singleton

C

Ensure a class only has one instance, and provide a global point of access to it.

Design Pattern Example Strategy

B

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it

Design Pattern Example Facade

JDBC APIDatabaseFacade

Clientuses

Connection

Statement

ResultSet

DatabaseMetadata

ResultSetMetadata

Driver…

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Design Pattern ExampleData Access Object

Alur et al.

S

ACCP i7.1\Sem3_4\eProject\T4

Design Principles

Programming to interfaces not implementations Favor composition over inheritance Encapsulate what varies Strive for loosely coupled between objects that interact Classes should OPEN for extension and CLOSE for

modification Depends on abstraction, not concrete classes Don't call us, we'll call you A class should have only one reason to change

ACCP i7.1\Sem3_4\eProject\T4

Best Practices

Use dynamic models to clarify main and\or complicated class relationship\algorithms, not for ‘obvious’ one

Stick to design principles for better design Use Design Patterns

ACCP i7.1\Sem3_4\eProject\T4

Software testing (for S4)

ACCP i7.1\Sem3_4\eProject\T4

References and Readings

E. Gamma, R. Helm, R. Johnson, & J. Vlissides. Design Patterns: Elements of Object-Oriented Software, Addison-Wesley, 1995.

D. Alur, J. Crupi and D. Malks, Core J2EE Patterns: Best Practices and Design Strategies, 2nd Edition, 2003

Fowler M. & Scott K., 1999, UML Distilled, Addison Wesley

Aptech India, OOAD Course, ACCP 2003 Curriculum