Week 11 -SWE202.pdf

SWE202 SOFTWARE CONSTRUCTION WEEK 11 Diagrams (SSDs), Operation contracts, System layers Oluwaseun Priscilla Olawale (MSc.) System Behavior System behavior is a description of what a system does, without explaining how it does...

SWE202 SOFTWARE CONSTRUCTION WEEK 11 Diagrams (SSDs), Operation contracts, System layers Oluwaseun Priscilla Olawale (MSc.) System Behavior System behavior is a description of what a system does, without explaining how it does it. One part of that description is a system sequence diagram. A system sequence diagram is a fast and easily created artifact that illustrates input and output events related to the systems under discussion. System Sequence Diagrams A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and inter-system events. A system sequence diagram is, as the name suggests, a type of sequence diagram in UML. It’s style and notation is dictated by the Unified Modeling Language SSD vs. Sequence and Use Case Diagrams Standard sequence diagrams show the progression of events over a certain amount of time, while system sequence diagrams go a step further and present sequences for specific use cases. Use case diagrams are simply another diagram type which represents a user's interaction with the system. SSD and Use Case Diagrams Standard sequence diagrams show the progression of events over a certain amount of time, while system sequence diagrams go a step further and present sequences for specific use cases. Use case diagrams are simply another diagram type which represents a user's interaction with the system. SSDs are part of the Use-Case Model—a visualization of the interactions implied in the use cases. SSD - Notations Objects - this box shape with an underlined title represents a class, or object, in UML. Within a SSD, this shape models the system as a black box (a system with inner workings that are not immediately visible). Actors - shown by stick figures, actors are entities that interact with the system, and yet are external to it. Events - the system events that the actors generate in the sequence. A dashed line, known as a lifeline, represents events in an SSD. Lifelines may begin with a labeled rectangle shape or an actor symbol.  SSD Example With SSD, all systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems. Operation Contracts Contracts for operations can help define system behavior; they describe the outcome of executing system operation in terms of state changes to domain objects. Contracts describe detailed system behavior in terms of state changes to objects in the Domain Model, after a system operation has executed. The contract of an operation is defined mainly in terms of its pre-conditions and post-conditions. Operation Contracts Pre-conditions are the conditions that the state of the system is assumed to satisfy or must hold true before the execution of the operation. Post-conditions are the conditions that the system state has to satisfy when the execution operation has finished, or the constraint that must hold true after the completion of an operation. Operation Contracts - Schema Operation—name of operation (parameters) Cross Reference—the Use Cases in which the OC occurs Preconditions—noteworthy assumptions about state of system or objects in DM before execution Postconditions—state of objects in DM after execution of operation Operation Contracts - Example Consider the SSD: Operation Contracts - Example The OC is given thus: