System Development Techniques Individual Assignment
Tubekbay001
Lesson6.pdf
System Development Techniques
Diploma in Information Technology
Lesson 6
Learning outcomes After studying this chapter and the recommended reading, you should be able to:
• Explain the use case descriptions • Discuss the activity diagrams for use cases • Describe design system inputs and outputs • Discuss the system sequence diagram • Explain the Use cases and CRUD • Describe the integrating requirements models
Use Case Descriptions
• A list of use cases and use case diagrams provides an overview of all the use cases for a system.
• Detailed information about each use case is described with a use case description.
Use Case Descriptions
• Use case descriptions tend to be written at two separate levels of detail: brief description and fully developed description.
• A brief description – enough detail for very simple use cases, especially when the system to
be developed is a small, well-understood application. – Examples of simple use cases are Add product comment or Send
message.
• A use case such as Fill shopping cart is complex enough that a fully developed description is also written after the initial brief use case description is finalized.
Use Case Descriptions
• Use cases and brief use case descriptions
Use Case Descriptions
• The fully developed description is the most formal method for documenting a use case.
• To create a comprehensive, robust system that truly meets users’ needs, must understand the detailed steps of each use case.
Use Case Descriptions
• No standard format. Many different format. • Common items in a Use case description
– Use case name – Scenario – Triggering event – Brief description – Actors – Related use cases – Stakeholders – Preconditions, Postconditions – Flow of Activities – Exception conditions – Etc.
Use Case Descriptions
Fully developed description sample
Use Case Descriptions
Fully developed description sample
Use Case Descriptions
• Scenarios (aka use case instances) – ONE flow of activity is ONE scenario. – The use case Create customer account will have a separate
flow of activities depending on which actor invokes the use case.
– The processes for a customer service representative updating information over the phone might be quite different from the processes for a customer updating the information him or herself.
– Another use case description would be written for the Create customer account by phone scenario.
Use Case Descriptions
• Preconditions – identify what the state of the system must be for
the use case to begin, – including what objects must already exist, – what information must be available, and even the
condition of the actor prior to beginning the use case.
Use Case Descriptions
• Postconditions – identify what must be true upon completion of the use
case. – indicate what new objects are created or updated by the
use case and how objects need to be associated. – For example, in the Create customer account use case, it is
important to test that a customer record, address record, and account record were successfully added to the database.
Use Case Descriptions
• Flow of activities – identifying the steps performed by the actor and
the responses required by the system.
• Alternative activities and exception conditions – The numbering of exception conditions also helps
tie the exceptions to specific steps in the flow of activities.
Activity Diagrams for Use Cases
• In previous you learned about activity diagrams as a form of workflow diagram that might cover several use cases.
• Activity diagrams are also used to document the flow of activities for one use case.
• Provides a more graphical view of the flow of activities.
Activity Diagrams for Use Cases
• Activity diagram for Create customer account
Activity Diagrams for Use Cases
• Activity diagram for Ship Items use case
Activity Diagrams for Use Cases
• Activity diagram for Fill shopping cart
• Activity diagrams are helpful when the flow of activities for a use case is complex.
• Three use cases: – Search for Product, – Look at product
reviews, – Search and view
accessories
Activity Diagrams for Use Cases
• Use case Fill shopping cart – three other use cases (Search for Product, Look at product
reviews, Search and view accessories) might be invoked while adding items to the shopping cart.
• The actor might search for a product and then look at product reviews before adding the item to the cart.
• Once an item is added, the actor might search for and view available accessories and then add one or more to the cart.
The System Sequence Diagram
• Object-oriented approach, – flow of information is achieved through sending messages
• to and from actors • back and forth between internal objects.
• A system sequence diagram (SSD) – describe flow of information into and out of the automated portion of
the system. – documents the inputs and the outputs and identifies the interaction
between actors and the system. – effective tool to help in the initial design of the user interface by
identifying the specific information that flows from the user into the system and the information that flows out of the system back to the user.
The System Sequence Diagram
• Generic system sequence diagram (SSD)
SSD Notation
• Stick figure represents an actor – In use case diagram, the actor “uses” the system, – SSD is on how the actor “interacts” with the system by
entering input data and receiving output data.
• The box labeled :System is an object that represents the entire automated system.
• SSD (and all other interaction diagrams), use object notation instead of class notation. – object notation, a rectangle with the name of the object
underlined.
SSD Notation
• Underneath the actor and :System are vertical dashed lines called lifelines.
• A lifeline, or object lifeline, is simply the ”life time” of that object or during the use case.
SSD Notation
• The arrows between the lifelines represent the messages that are sent by the actor.
• The sequence of messages is read from top to bottom in the diagram. • A message – labeled to describe its
purpose and any input data being sent.
– name should follow the verb-noun syntax to make the purpose clear.
SSD Notation
• Returned value – A dashed arrow indicates a response or an answer
(in programming, a return), – immediately follows the initiating message. – it is a response, only the data that are sent on the
response are noted.
SSD Notation
• A note can be added to any UML diagram to add explanations.
SSD Notation
• Frequently, the same message is sent multiple times in a loop, – For example, when an actor enters items on an order, the message to
add an item to an order may be sent multiple times. – The message and its return are located inside a larger rectangle called
a loop frame.
SSD Notation
• Alternate notation for loop – [true/false condition] return-value := message-name
(parameter-list) – The asterisk (*) preceding the true/false condition
indicates that the message repeats as long as the true/false condition evaluates to true.
SSD Notation
• The opt frame is used when a message or a series of messages is optional or based on some true/false condition.
SSD Notation
• The alt frame is used with if-then-else logic.
Developing a System Sequence Diagram (SSD)
• An SSD is used in conjunction with the use case descriptions to help document the details of a single use case or scenario within a use case.
• To develop an SSD, it is useful to have a detailed description of the use case—either in the fully developed form or as an activity diagram.
Developing a System Sequence Diagram (SSD)
• An SSD is used in conjunction with the use case descriptions to help document the details of a single use case or scenario within a use case.
• SSD provide explicit identification of inputs and outputs.
• Easy to identify when an input or output occurs in SSD. – Inputs and outputs occur whenever an arrow in an activity
diagram goes from an external actor to the computer system.
Developing a System Sequence Diagram (SSD)
• Development steps of SSD 1. Identify the input messages 2. Describe the message from the external actor to
the system by using the message notation described earlier.
3. Identify and add any special conditions on the input messages, including iteration and true/false conditions.
4. Identify and add the output return messages.
Developing a System Sequence Diagram (SSD)
1. Identify the input messages
• Three locations with a workflow arrow crossing the boundary line between the customer and the system.
• At each location that the workflow crosses the automation boundary, input data are required; therefore, a message is needed.
Developing a System Sequence Diagram (SSD)
2. Describe the message from the external actor to the system by using the message notation described earlier.
• The names of the messages reflect the services that the actor is requesting of the system: createNewCustomer, enterAddress, and enterCreditCard.
• Instead of enterAddress, the name could be createAddress. The point to remember is that the message name should describe the service requested from the system and should be in verb-noun form.
Developing a System Sequence Diagram (SSD)
3. Identify and add any special conditions on the input messages, including iteration and true/false conditions.
• The enterAddress message is repeated for each address needed for the customer.
• The asterisk symbol in front of the message is shown
Developing a System Sequence Diagram (SSD)
4. Identify and add the output return messages.
• Two options for showing return information:
• as a return value on the message itself
• as a separate return message with a dashed arrow.
• Return messages are each named with a noun that indicates what is being returned.
• Sometimes, no output data are returned.
Developing a System Sequence Diagram (SSD)
• The objective of developing SSD is to discover and understand user requirements
• Analyst should be working closely with users to define exactly how the workflow proceeds and exactly what information needs to be passed in and provided as output.
• This is an iterative process, and analyst will probably need to refine these diagrams several times before they accurately reflect the needs of the users.
Use Cases and CRUD Create, Read/Report, Update and Delete
• Technique to validate use cases • Involves verifying that all of the needed use cases
have been identified to maintain the data represented by the domain model class diagram.
• To validate and refine use cases, the analyst looks at each type of data and verifies that use cases have been identified that create the data, read or report on the data, update the data, and delete (or archive) the data.
Use Cases and CRUD Create, Read/Report, Update and Delete
• Take already identified use cases and verify that there are use cases for create, read, update, and delete as a cross-check.
Use Cases and CRUD Create, Read/Report, Update and Delete
• Another use – summarize all use cases and all data entities/domain classes to show
the connection between use cases and data.
CRUD table showing use cases and corresponding domain classes
Use Cases and CRUD Create, Read/Report, Update and Delete
• For example, – the use case Create customer account actually creates customer data
and account data, so the C is included in those two cells. – The use case Process account adjustment reads information about the
sale, reads information about the customer, updates the account, and creates an adjustment.
Use Cases and CRUD Create, Read/Report, Update and Delete
• Based table, there are insufficient use cases to cover the Sale and the Adjustment domain classes. – The Sale class will need to have additional use cases to create, update, and
delete Sale objects. I – The Adjustment class will require use cases to update, report, and delete
Adjustment objects.
Use Cases and CRUD Create, Read/Report, Update and Delete
• The CRUD technique for validating and refining use cases includes these steps: 1. Identify all the domain classes involved in the new system. 2. For each type of data (domain class), verify that a use case has been
identified that creates a new instance, updates existing instances, reads or reports values of instances, and deletes (or archives) an instance.
3. If a needed use case has been overlooked, add a new use case and then identify the stakeholders.
4. With integrated applications, make sure it is clear which application is responsible for adding and maintaining the data and which system merely uses the data.
Integrating Requirements Models
• Iterative approach – only construct the diagrams that are necessary for a given iteration.
• Complete use case diagram to get an idea of the total scope of the new system. – the supporting details included in use case descriptions, activity
diagrams, and system sequence diagrams need only be done for use cases in the specific iteration
• Not all use cases need to be modeled in detail.
Integrating Requirements Models
• The domain model class diagram should be as complete as possible for the entire system early in the project.
• Refinement and actual implementation of many classes will wait for later iterations, but the domain model should be fairly complete.
• The domain model is necessary to identify all the domain classes that are required in the new system.
• The domain model is also used to design the database.
Integrating Requirements Models
• Construction of a diagram depends on information provided by another diagram.
• Development of a new diagram often helps refine and correct a previous diagram.
Relationships among object-oriented requirements models
Integrating Requirements Models
• The solid arrows represent major dependencies. • The dashed arrows show minor dependencies. • The dependencies generally flow from top to bottom, but
some arrows have two heads to illustrate that influence goes in both directions.
Integrating Requirements Models
• Development of detailed diagrams is critical to gain a thorough understanding of the user requirements. – The use case diagram, use case description and Activity diagrams used
to capture the processes of the new system. – The class diagram and its dependent diagrams capture information
about the classes for the new system.
Integrating Requirements Models
• The use case diagram and the domain model class diagram are the primary models from which others draw information.
• Should develop those two diagrams as completely as possible.
Integrating Requirements Models
• The detailed descriptions either in Use case description or in activity diagrams, – provide important internal documentation of the use cases – must completely support the use case diagram. – are important for development of system sequence diagrams.
• The detailed descriptions, activity diagrams, and system sequence diagrams must all be consistent with regard to the steps of a particular use case.
• Understanding the relationships among these models is an important element in the quality of the models.
Summary
• Use cases and use case diagrams provides an overview of all the use cases for a system.
• Detailed information about each use case is described with a use case description.
• Use case descriptions tend to be written at two separate levels of detail: brief description and fully developed description.
Summary
• Activity diagrams are also used to document the flow of activities for one use case.
• Provides a more graphical view of the flow of activities.
• A system sequence diagram (SSD) – describe flow of information into and out of the
automated portion of the system. – documents the inputs and the outputs and identifies the
interaction between actors and the system.
Summary
• CRUD technique is to validate use cases • CRUD Involves verifying that all of the needed
use cases have been identified to maintain the data represented by the domain model class diagram.
Summary
• The detailed descriptions, activity diagrams, and system sequence diagrams must all be consistent with regard to the steps of a particular use case.
• Understanding the relationships among these models is an important element in the quality of the models.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 5
