System Development Life Cycle and UML

• System Development Life Cycle (SDLC) is followed when developing systems
• The stages of the SDLC are:
  • Requirements Analysis
  • Design
  • Development
  • Integration and Testing
  • Operations & Maintenance

The Modeling Language UML

• UML stands for Unified Modeling Language
• UML is a graphical language used for:
  • Specifying
  • Visualizing
  • Constructing
  • Documenting
• UML is used to model artifacts of software systems
• An approved ISO standard, UML was first adopted in 1997 by the Object Management Group (OMG)
• Since 2005, the standard has been periodically revised to remain current

UML Diagram Types

• There are 14 UML diagram types
• There are 2 main categories of UML modeling diagrams:
  • Structural Diagrams
  • Behavioral Diagrams
• Structural modeling captures the static features of a system, including:
  • Class Diagram
  • Object Diagram
  • Deployment Diagram
  • Package Diagram
  • Composite Structure Diagram
  • Component Diagram
• Structural modeling represents the framework for a system
• Structural modeling describes the elements and mechanisms to assemble them
• Structural modeling does not describe dynamic behavior
• Behavioral modeling describes the interaction in a system
• Behavioral modeling represents the interaction among the structural diagrams
• Behavioral modeling shows the dynamic nature (dynamic sequence of flow) of the system
• Behavioral modeling includes:
  • Use case diagram (UCD)
  • Sequence diagram
  • Collaboration diagram
  • State machine diagram
  • Activity diagram
  • Communication diagram
  • Interaction overview diagram
• UML Use Case and Class diagrams can be used in SDLC

Role of Use Case Diagrams in SDLC

• Use case diagrams depict the various users of the system and how they use it
• Shows how the system requirements will be met.

Role of Class Diagrams in SDLC

• Class diagrams depict the classes, their attributes, operations, and relationships

Use Case Diagrams

• The purpose of a Use Case (UC) diagram is to visualize the functional requirements of a system defined in the SRS document
• Use case diagrams provide a formal way to represent how a business system interacts with its environment
• Use case diagrams illustrate the activities performed by users of the system
• Use case diagrams are a scenario-based technique in the UML

Elements of a Use Case Diagram

• When drawing a use case diagram, there are four key elements need to be determined:
  • The system being used
  • The actor(s) involved
  • Each use case, which is a summary of scenarios for a single task or goal
  • Relationships
• Key elements can be described as:
  • System boundary: Represents the boundary between the physical system and actors
  • Actors: Can be a human, peripheral device (hardware), external system/subsystem, or time/time-based event
  • Use case: Summary of scenarios for a single task or goal; represents functionality for an actor, named by verb
  • Relationship: Depicts interactions between actors and use cases
• Each use case describes one function in which users interact with the system and may contain several paths; each path is a scenario

Use Case Diagram: Bank ATM example

• Automated teller machine (ATM) or the automatic banking machine (ABM) is a banking subsystem that provides bank customers with access to financial transactions in a public space without the need for a cashier, clerk or bank teller.
• Customer (actor) uses bank ATM to check balances of his/her bank accounts, deposit funds, withdraw cash and/or transfer funds (use cases).
• ATM Technician provides maintenance and repairs. All these use cases also involve Bank (customer account system) actor whether it is related to customer transactions or to the ATM servicing.

Scenarios

• Use cases comprise one or more scenarios
• A scenario is a series of steps describing a course of action through a use case
• Steps vary between actors and the system
• All use cases have a primary scenario, often called the "Sunny Day Scenario" or "Happy Path," representing the main flow of events
• A use case usually has secondary scenarios
  • Usually include one or more alternate flows
  • May describe exception conditions or options
• Alternate flows describe what happens when business rules are violated or errors/exception conditions occur considered “normal business” exceptions
• Common exceptions:
  • Wrong password typed
  • Invalid credit card
  • Part not available

Relationships between Use Cases

• Include: use cases that are included as parts of other use cases
• Extend: use cases that extend the behavior for the other use cases
• Generalization: specifies how a child can specialize all behavior and characteristics described for the parent

Core Relationships

• 5 types of relationships:
  • Association: Between an actor and a use case.
  • Extend: Between two use cases.
  • Include: Between two use cases.
  • Generalization: Of a use case.
  • Generalization: Of an actor.
• Associations between actors and use cases indicate that the actor and the use case communicate with one another using messages
• Arrow direction indicates who initiated the interaction

Include Relationships Example

• A base use case to an inclusion use case specifies behavior for inclusion, upon which the base use case depends
• Avoids describing same flow of events & puts the common behavior in use case of its own
• The include relationship simplifies large use to split into several or extract parts of two or more use cases

Extend Relationships Example

• The base use case implicitly incorporates behavior of another at extension points and doesn't depend on the extension use case
• Condition of extend & extension points references (optionally) shown in comment note attached to corresponding extend relationship

Use Case Generalization Relationships Example

• Child inherits behavior and meaning of parent & child may add to or override parent behavior

Actors Generalization:

• One actor inherits the role of another actor
• The descendent inherits all use cases of the ancestor
• The descendent has one or more use cases specific to that role

Rules and Tip for Use Case Diagrams

• At least one use case
• At least one actor
• At least one use case associated with each actor
• No association line between actors
• No association line between use cases
• Name every actor and use case
• Don't label any association line
• Ensure the use case describes a significant segment of system use that is understandable by both domain experts and programmers
• When factoring out common usages required by multiple use cases:
  • Use include if the usage is required
  • Use extend if the base use case is complete and usage is optional
• A use case diagram should contain only use cases at the same level of abstraction and include only required actors
• Do not treat use-cases as functions in a program, avoid excessive breakdown into smaller entities
• Use-cases (even mini ones) should always have documentable interaction between the actor and system with a minimum two tasks