1 / 23

Embedded Systems Architecture Design Criteria

Explore requirements, architecture, and implementation for embedded systems, focusing on usability, security, efficiency, correctness, and reliability. Learn about domain analysis, system definition, and interfaces.

thiery
Télécharger la présentation

Embedded Systems Architecture Design Criteria

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering Lecture 2 ASPI8-4 Anders P. Ravn, Feb. 2004

  2. Your Report - 2! • Requirements Specification • 1.1 System Definition • 1.2 Problem Domain Structure • 1.3 Application Domain Structure • 1.3.1 Use Cases • 1.3.2 Functions • 1.3.3 Interfaces • 1.4 Acceptance Test Specification • Architecture • 2.1 Criteria • 2.X Module Interfaces • 2.T Integration Test Specification

  3. Overview • Software Requirements • OAD in Application Domain Analysis Architecture for Embedded Systems • Usage • Functions • Interfaces

  4. Activities: application domain analysis System definition and Problem Domain models Interfaces Usage Application Domain Model and Software Requirements Functions

  5. Use Case <<actor>> name <<actor>> name name <<actor>> name

  6. Activities: use case analysis System definition Use cases Evaluate systematically Analyse work tasks Structure the use cases Find actors and use cases

  7. Example: Start tool use <<actor>> TractorOperator <<actor>> RowWeeder start_tracking Each use case is described textually and/or by a behaviour diagram

  8. Actor stereotype start_tracking <<actor>> RowWeeder TractorOperator

  9. Functions • The actions of actors in use cases: • Update – state change in (internal) model • Signal – event in (internal) model • Read – (internal) modelstate inspection • Compute – (internal) model state summary Update/ Read/ Compute <<actor>> System Signal

  10. Interfaces IPanel Update/ Read/ Compute System <<Interface>> Alarm Signal

  11. Example: User Interface

  12. Example: Camera Interface The camera delivers JPEG compressed images with a frame rate of up to 10 per second. The resolution is ... The hardware interface is a DMA ... The standard software driver is ...

  13. Summary: Application Domain Analysis • Use Cases • Functions • Interfaces

  14. Your Report - 3! • Requirements Specification • 1.1 System Definition • 1.2 Problem Domain Structure • 1.3 Application Domain Structure • 1.3.1 Use Cases • 1.3.2 Functions • 1.3.3 Interfaces • 1.4 Acceptance Test Specification • Architecture • 2.1 Criteria • 2.X Module Interfaces • 2.T Integration Test Specification

  15. Design criteria • Usable • Secure • Efficient • Correct • Reliable • Maintainable • Testable • Flexible • Comprehensible • Reusable • Portable • Interoperable

  16. Architecture

  17. Interface Class and Dependency Segmentation PositionUpdate IRow use <<interface>> IRow use realise

  18. Package name related classes

  19. Active Class name

  20. Processes • Method in passive class - called from main • Method in passive class - linked to an Event • Method run in active class – explicit start Specified in UML by Statechart Diagram

  21. Signals and Events • Signals are asynchronous events • A Signal or Event is a Class • A method may have a send dependency on a Signal • A method that recieves a Signal has a use dependency

  22. Sensors, Actuators and Control Architecture for Embedded Systems • Sensors have passive interfaces with event methods • Actuators have passive interfaces with event methods • Control is active and uses sensors and actuators

  23. Your Report - 4! • Requirements Specification • 2. Architecture • 2.1 Criteria • 2.X Module Interfaces • 2.T Integration Test Specification • Modules • 3.X.1 Module Interface • 3.X.2 Module Design • 3.X.3 Module Test Specification • Implementation • Test

More Related