Real time requirements l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 38

Real-time requirements PowerPoint PPT Presentation


  • 78 Views
  • Uploaded on
  • Presentation posted in: General

Real-time requirements. Intro to Software Engineering Software Development Process Models Formal methods in software specification Structured Analysis Object-oriented analysis and the UML Use Cases. Object-oriented analysis– Use Case. Use Case diagram of inertial measurement system. .

Download Presentation

Real-time requirements

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Real time requirements l.jpg

Real-time requirements

  • Intro to Software Engineering

  • Software Development Process Models

  • Formal methods in software specification

  • Structured Analysis

  • Object-oriented analysis and the UML

    • Use Cases


Object oriented analysis use case l.jpg

Object-oriented analysis– Use Case

Use Case diagram of inertial measurement system.


Context diagram l.jpg

Context diagram

Inertial Measurement System


Example library use case diagram l.jpg

Example: Library Use Case Diagram

A computerized library system for a university keeps track of all books and periodicals in the library and their check-out status. Checkout and return are automated through a bar code reader (an external device). The library system also interfaces with an external relational database which stores information about the library users (students, faculty, and staff), including whether they have any library items checked out. . Library users can access the catalog and recall books and periodicals. Library employees have the same access as well as additional capabilities (e.g., listing the status of an item). (Note: the library catalog is part of the library computer system so it is not shown as an actor.)


Use case for employee login l.jpg

Use Case for Employee Login

  • Employee initiates use case by entering user name

  • System prompts for password

  • If password is valid, employee is logged on and now has access to employee commands

  • Starting and Ending Conditions?

  • Exceptions? e.g., cannot find the employee login


Use case for check book availability l.jpg

Use Case for Check book availability

  • User/Employee initiates use case by selecting the check book availability option

  • System prompts for choice of search by title, author, or call number

  • User makes selection and enters title, author or call number

  • System performs search through the library catalog database

  • If a match is found, system displays item status (not checked out, checked out and due date, overdue)

Starting and Ending Conditions?

Exceptions?


Include functional decomposition l.jpg

<<Include>>: Functional Decomposition

  • Problem:

    • A function in the original problem statement is too complex to be solvable immediately

  • Solution:

    • Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use cases

CreateDocument

<<include>>

<<include>>

<<include>>

Check

OCR

Scan


Include reuse of existing functionality l.jpg

<<Include>>: Reuse of Existing Functionality

  • Problem:

    • How can we reuseexisting functions?

  • Solution:

    • The include association (“A delegates to B”)

  • Note: The base case cannot exist alone. It is always called with the supplier use case

<<include>>

OpenIncident

Base Use

Case

ViewMap

<<include>>

Supplier

Use Case

AllocateResources


Slide9 l.jpg

Home Automation example –

factor out common functionality


Slide10 l.jpg

Another Home Automation example –

factor out common functionality


Extend association for use cases l.jpg

Base Use

Case

B

Help

FieldOfficer

A

<<extend>>

ReportEmergency

<<Extend>> Association for Use Cases

  • Problem:

    • The functionality in the original problem statement needs to be extended.

  • Solution:

    • An extend association: B is an extension of A.

  • Note: In an extend association, the base use case can be executed without the use case extension


Home automation example l.jpg

Home Automation example


Generalization association in use cases l.jpg

Generalization association in use cases

  • Problem:

    • You have common behavior among use cases and want to factor this out.

  • Solution:

    • The generalization association factors out common behavior.

CheckPassword

Parent

Case

Child

Use Case

ValidateUser

CheckFingerprint


Slide14 l.jpg

Example using <<extend>>


Slide15 l.jpg

Simplified with an abstract use case


Slide16 l.jpg

Anesthesia Machine Use Cases


Slide17 l.jpg

Decomposition of the Deliver Anesthesia Use Case


Slide18 l.jpg

Use Case Activity Breakdown


Slide19 l.jpg

Ventilator Use Cases


Slide20 l.jpg

User Interface Use Cases


Slide21 l.jpg

Vaporizer Use Cases


Slide22 l.jpg

SPO2 Monitor Use Cases


Slide23 l.jpg

CO2 Monitor Use Cases


Slide24 l.jpg

Agent Monitor Use Cases


Slide25 l.jpg

Breathing Circuit Use Cases


Slide26 l.jpg

Bad Use Case Modeling


Slide27 l.jpg

Adding a

Textural

Characterization


Slide28 l.jpg

Use Case Relations


Slide29 l.jpg

Relating Text and Scenarios


Slide30 l.jpg

Use Case Sequence Diagram


Slide31 l.jpg

Deliver Anesthesia Collaboration


Slide32 l.jpg

Elaborated Scenario Part 1


Slide33 l.jpg

Elaborated Scenario Part 2


Slide34 l.jpg

Alarm On Critical Event Statechart


Slide35 l.jpg

Statecharts

and

Sequence

Diagrams


Slide36 l.jpg

Display Waveform Activity Diagram


Slide37 l.jpg

Use Case Timing Diagram


Best practices in specifying requirements l.jpg

Best practices in specifying requirements

  • Bad:

    • The systems shall be completely reliable.

    • The system shall be modular.

    • The system shall be maintainable.

    • The system will be fast.

    • Errors shall be less than 99%.

  • Better:

    • Response times for all level one actions will be less than 100 ms.

    • The cyclomatic complexity of each module shall be in the range or 10 to 40.

    • 95% of the transactions shall be processed in less than 1 s.

    • An operator shall not have to wait for the transaction to complete.

    • MTBF shall be 100 hours of continuous operation.


  • Login