Software Engineering Design Architecture Module 5 Modeling Behavior

Software Engineering & Design Architecture Module 5 Modeling Behavior with Sequence Diagrams

Introduction l Sequence diagrams • Model object interactions arranged in time • • sequence Distribute use case behavior to different classes Illustrates all paths a use can produce

Introduction l l Use cases are necessarily generic Sequence diagrams enhance the design by adding detail

Introduction l Example: Use Case: Compile Application • What are all the possible workflows for such a use case?

Introduction l Possible problems: l Without modeling when would you account for these errors? • Source file not found • Syntax errors in source file(s) • I/O errors in file system • During development! • Probably would not use reusable code either

Sequence Diagram Notation l Two major components: • Active objects • Anything that plays a role in the system: object instance or actor • Messages • Communication between these objects l The messages between the objects are the key to a sequence diagram

Sequence Diagram Notation l Active Objects Time Lifeline

Sequence Diagram Notation l Messages from Object. One to Object. Two

Sequence Diagram Notation l Active objects can include actors Time t+1 Time t+2

Sequence Diagram Notation l Messages are not restricted to adjacent objects

Sequence Diagram Notation

Communication with Messages l Messages may contain conditions • Message not sent unless condition met

Communication with Messages Object tells itself to do something

Communication with Messages

Communication with Messages l Message types • Synchronous • Flow interrupted until message (and any submessages) has been completed • Return • Control returned to calling object. • Synchronous message has been completed

Communication with Messages l Message types (cont. ) • Asynchronous • Sending object does not wait for a response • Flat • Neither synchronous nor asynchronous

Communication with Messages l Synchronous messages • Shows procedure flow where one • functionality is executed before another Important that one message be received and completed before execution continues

Communication with Messages Indicates interface does not regain control until response from database wrapper is received User does not regain control until response from interface is received

Communication with Messages l Asynchronous messages • Control flow does not need to be interrupted • before continuing Notifications or progress information for example

Communication with Messages

Communication with Messages l Flat messages • Sometimes we don’t care (or don’t know) if message should be synchronous or asynchronous

Communication with Messages

Communication with Messages l Creating Objects • Mandatory step: create object • Afterwards communicate as normal • Optional step: destroy object • Examples: • Display message box • Create file • Instantiate a class • Open database connection

Communication with Messages

Communication with Messages l Branching Flows • Indicates a change in the control flow to two or • more objects Based on some condition

Communication with Messages

Communication with Messages l Alternative Flows • Indicates a change to an alternate lifeline of • the same object Based on some condition

Communication with Messages