324 Chapter 7
Devops - A Trend of Systems Development DevOps (a clipped compound of "development" and "operations") is a software engineering practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.
"The focus now is on development efficiency through automation," says David Linthicum, senior VP of cloud technology partners, "and the ability to perform tasks more quickly and more effectively. Devops has been a big push for the last several years, and they require new roles to make devops organizations effective."
Delete message Object 1 delete Object 2 and Object 3 (stopping their lifelines)
7.8 Guidelines for Drawing Sequence Diagrams Sequence diagram is one of three interaction diagrams (sequence, communication, and timing) which describe interactions between system components (e.g., objects). Sequence diagrams are often used with use case to provide more detailed descriptions of system dynamic behavior or functionality over time. Below are sample guidelines. Start with small and simple and iteratively make improvement. The iterations of drawing UML diagrams not only cross SDLC stages but also inside of each SDLC stage such as systems analysis process. In addition, updating one diagram (e.g., class diagram) may also require updating other diagrams (e.g., sequence diagrams).
Object Symbol represents a class/object (or a system component) roles, don't list object attributes. Activation represent the time a class/object needs to complete a task; the longer the task will take, the longer the activation box; it is a thin rectangle placed vertically on its lifeline. Lifeline vertical dashed line indicates the class/object's presence over time; a lifeline begins with a object or an actor.
Actor a user or an external system in the use case diagram; in the sequence diagram, the actor interacts with objects over time; like an object, an actor also takes on lifeline which represents the actor's action over time. Message Symbols Synchronous Message: is used when the sender object must wait for the receiver object's response before it carries on with another message; it is represented as a solid line with a solid arrowhead. Asynchronous message: is used when the sender object does NOT wait for the receiver object's response before it carries on with another message; it is represented as a solid line with a lined arrowhead. Note: both synchronous and asynchronous messages are connected to two (objects') lifelines with the arrow pointing to the receiver object.
Examples of Sequence Diagram Notations (cont.) Return message
Examples of Sequence Diagram Notations (cont.) Create message Object 1 creates Object 3
Examples of Sequence Diagram Notations An interaction between two objects occurs when one object sends a message to another. The activation bars on the lifelines of the Message Caller and the Message Receiver indicate that both are active/is instantiated (object was created from its class) during the exchange of the message.
Examples of Sequence Diagram Notations (cont.) Synchronous and asynchronous messages
This diagram describes the entire iterative and incremental SDLC in object-oriented systems (OOS)
Full Use Case Use case fundamentally describes Users' needs Business processes which the system must perform. Use case can be used to describe the system functions (behaviors) at two levels: brief use case (discussed in chapter 6) and full use case. Full use case provides more detailed descriptions on a use case diagram which show how users (actors) interact with the system (cases) as well as the interaction of one system component with another. Full use case provides information about each use case, including actors, stakeholders, preconditions, post conditions, the flow of activities and exceptions conditions.
Full use case intends to provide more detailed descriptions of the system's dynamic behavior which actually is the interactions or message exchanges between the system's components (e.g., classes/objects). Sequence diagrams specifically focus on the "lifelines" of classes/objects and how they communicate with each other to perform a function before the lifeline ends. Accordingly, systems analysts often use sequence diagrams to show how objects interact with each other to perform the behavior of all or part of a use case. Sequence diagrams are a type of interaction diagram in that they describe in what order a group of objects works together. Now we can see sequence diagrams link behavior modeling (e.g., use case diagram) to domain modeling (e.g., class diagram).
In sum, sequence diagrams represent the details of a UML use case. model the logic of a sophisticated procedure, function, or operation. see how tasks are moved between objects or components of a process. plan and understand the detailed functionality of an existing or future scenario. (https://www.lucidchart.com/pages/uml/sequence-diagram) A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. Sequence diagrams allow the specification of simple runtime scenarios in a graphical manner (see more details of sequence diagram in the following example). Sequence diagrams are used in the analysis and design phases.
We have conducted systems analysis (i.e., requirement modeling) from two perspectives: structural view and behavioral view. Domain model (e.g., class diagram) describes system requirements from structural view. Use case diagram as a behavior model provides a behavioral view of system requirements at the high level. The use case diagram we learnt in Chapter 6 is very brief and they provide us a high-level behavioral picture of the interactions among users, external systems, and internal system functional components. This behavioral picture only describes what communications or interactions users and system components, that is, what functions a system component (e.g., use case) provides for a user. We call this high-level use case "brief use case". To better understand system requirements, we need more detailed descriptions of system behaviors. As such we need "full use case" to better understand the system requirements. Full use case not only requires more detailed textual descriptions but also other UML diagrams.
It makes sense to draw brief use case diagrams first since they provide high-level view of system requirements, followed by other behavior diagrams (e.g., activity diagram, sequence diagram) to show more detailed activities of information flow (i.e., system functions). Since different model/diagram intends to describe the system functions from different perspectives, there is no rules to guide which diagram(s) should be drawn first. This depends on the problem domain and the unique natures of the system development process as well as the systems analyst's personal preference - what they want to understand first. For example, "treat patient" can be a use case or an activity (which provides more detailed description of a action flow such as measuring blood pressure, taking blood samples, giving intravenous (IV) injection, etc.). Accordingly, drawing either use case diagram or activity diagram first would be fine and this all depends on what the systems analyst wants to understand first.
Message Symbols (cont.) Create Message: a message that creates a new object; the message is sent to a lifeline to create an object; it represents as a solid line with a lined arrowhead pointing to the object (rectangle box) created. Note: the system can dynamically create objects during the run-time. For example, a credit report is created when the system needs to process car loan; the event (message) processing car loan create the credit report object. Creating object is an asynchronous message. If the created object does something immediately after it is created, an activation box must be added right below it.
Message Symbols (cont.) Delete Message: a message that destroys an object; it represented a solid line with a solid arrowhead followed by an X symbol.
Message Symbols (cont.) Asynchronous Return Message: used to show that the message receiver object has completed processing the message and returns the control back to the message sender object; it is represented as a dashed line with a lined arrowhead. Note: to avoid cluttering up the diagram, we do NOT draw the return message for the synchronous message since a synchronous message always implies a return message and the return message/value can be specified in the sending message.
Message Symbols (cont.) Self (Reflexive) Message: shows an object sends a message to itself; it is represented as a U-shaped arrow pointing back to itself. Note: no need of distinguishing synchronous or asynchronous message since the object sends a message to itself.
In IS 324, I suggest we start a brief use case diagram (behavior model), followed by class diagram (domain model), and then activity diagram and sequence diagram (behavior models) again. This is an iterative process! All UML diagrams complement each other rather than substituting each other. UML intends to provide as much comprehensive description of the system requirements as possible. However, there is a major challenge and criticism when UML becomes widely adopted. UML has many diagrams (models) and they are complicated and not easy to use. UML doesn't provide good rules to guide how to use the diagrams. This dilemma fully reflects the nature of today's SDLC - SDLC is a complex task and no single method or tool can solve the whole problem and thus SDLC needs high creative and critical thinking skills. Personally, I think AI (Artificial Intelligence) would help UML usages in object-oriented systems analysis and design in the future.
Requirement modeling can start with use case modeling and domain modeling at the same time, or one after another. Regardless which goes first, the requirement models must deliver behavioral and structural description of the system.
Typical use case description templates include: Use case name: verb-noun Scenario (if needed): a use case can have more than one scenario (e.g., special case) Triggering event: based on event decomposition technique Brief description: briefly describe an identified use case (e.g., "sign contract") Actors: can be users and other external systems Related use cases: one use case related to another (e.g., <<include>>, <<extend>>) Stakeholders: anyone with an interest in the use case Preconditions: what must be true before the use case begins Postconditions: what must be true when the use case is completed can be used planning test case expected results Flow of activities: the activities that go on between actors and the system Exception conditions: where and what can go wrong
Sequence Diagram A sequence diagram shows object interactions arranged in time sequence. It depicts the objects/classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams are typically associated with use case realizations in the logical view of the system under development. Sequence diagrams are sometimes called event diagrams or event scenarios. A sequence diagram thus describes an interaction by focusing on the sequence of messages that are exchanged, along with their corresponding occurrence specifications on the lifelines (objects' lifelines).
A sequence diagram illustrates the system functional activities over time. The sequence diagram symbols illustrated here are not a complete list. Systems analysts can add and use more symbols as needed in order to better describe the system requirements. That is, every system has different uniqueness and complexity from others and each SDLC stage has different requirements and descriptions for the same system, and thus systems analysts may use extra UML symbols in their diagrams to better reflect their system analysis and design. For example, there are more sequence diagram symbols. They are Found Message, Lost Message, Option Loop Symbol, Package Symbol, etc. We do not use these symbols in this class - we only use the basic sequence diagram symbols as we discusses in the previous slides.
Systems analysts often add a comment box to give textual explanation to a UML diagram or a specific symbol. For example, the comment below is given to its related object with a dashed line. The comment object is a rectangle with a folded-over corner as shown below. The comment box includes a short textual explanation to its related object. The comment object is used for many UML diagrams (e.g., class, sequence).
Guidelines for Drawing Sequence Diagrams (cont.) Don't add too much details in one diagram. Instead, draw a few smaller sequence diagrams that appropriately describe what the system or a use case does. The diagram should fit on a single page and leave space for explanatory notes as well. Instead of drawing many (e.g., dozens) of sequence diagrams, try to consolidate common scenarios and rethink any more efficient ways to make each diagram to focus on one major behavior and reduce any redundancy. If all stakeholders well understand certain behavior/functionality, no need to draw diagrams for it, but the requirements (for this functionality) are still needed to document (e.g., notes).
The bank quote gateway aggregates the responses from the banks and chooses the best quote from all the quotes received. The response is sent back to the loan broker, which formats the data from the best quote and returns the report to the client.
Summary of Sequence Diagrams Sequence diagrams describe interactions between system components (e.g., objects) over time. It is difficult to draw sequence diagrams for the system which has too many interactions between components, particularly, when interactions occur under certain conditions, for example, "create a car loan only if the credit report meets a criteria". Using conditions in sequence diagrams adds more complexity and difficulty for drawing sequence diagrams. See the following example. Using conditions in sequence diagrams is very common. However, using conditions is NOT required in IS 324 - we only use the very basic sequence diagram notations as we discussed in previous slides.
Wrap-up of Systems Analysis We wrap up the systems analysis with sequence diagram in this chapter. We have discussed behavior modeling with use case, activity and sequence diagram and structure modeling with class diagram in UML. UML is a graphic modeling language for systems analysis and design. UML diagrams provide graphic descriptions of system functionality. Accordingly, UML diagrams are only used for functional requirement modeling. UML doesn't model non-functional or technology requirements.
