y2 eprojects
DESCRIPTION
Y2 eProjects. Session 4 – Advanced Topics. Objectives. Dynamic Models Design Patterns (Optional) Software testing (for S4 ). Dynamic Models. Message and Message Notations. - PowerPoint PPT PresentationTRANSCRIPT
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