Real-Time Embedded Systems

Real-Time Embedded SystemsAssist. dr. Barbara Koroui [email protected](01) 4773-363

Joef Stefan International Postgraduate School

Where we have been... (1)Computers inside a system...


Where we have been... (2)ESs must meet requirements of:Real-time.Resource consumption (CPU, memory, power, physical space).Dependability (safety, reliability).Long-life systems (reusability, flexibility, portability). Interoperability.


Where we are going today...Designing and developing real-time softwareImplementation and performance issues


Designing and developing real-time softwareDiagrammingPractical diagramming methodsDesigning & constructing software


1. Diagramming


A typical design&development process in the past (?)Programmers thought about the problem to be solved.They wrote lines of code to solve it.The code was tested and modified until it was correct.This source code was released as the system documentation.

In 1999, General Motors had to recall 3.5 million vehicles because of an anti-lock braking SW defect. Stopping distances were extended by 15-20 meters. Federal investigators received reports of 2,111 crashes and 293 injuries.


TodayPractically all modern SW tools use diagrams as an integral part of the design & development process!What is a diagram?Partial graphical representation of a system's model, dealing with aspects:Problem recognition.Modularity.Tractability.Sequence.Circumstance.


Why use diagrams?As a DESIGN toolAs a COMMUNICATION mediumAs a MAINTENANCEtoolAs a DOCUMENTATIONtechnique


ESs are not trivial!


Diagrams for documentationHigh-level diagrams:Task oriented.Overall system structure + major subsystems.Overall functioning of the design.Interaction of the system with its environment.Functions & interactions of the subsystems.Low-level diagrams:Solution-oriented.Details.System internal information.


Diagrams for maintenanceDont forget: System maintenance is usually carried out by workers who:Werent involved in the development in the first place.Have only a limited understanding of the overall task.Have to learn a lot very quickly to perform even small design changes.


Good diagramming featuresSmallSimpleClearCompleteFew abstract symbolsUse formal rulesThe design approach must be stated in terms of the problem not its solution!


Overall diagram set for RT & E systems

Always use a diagram set, which is in common use;forms part of accepted design methods;is supported by tools.System requirements/specificationsSystem contextSystem configurationSystem architectureSystem usageSystem SW/HW structureSystem & SW behaviourSW distributionSystem & SW designUMLSysML


Design aspects (1)System context:All external entitiesEntity attributesThe relationship of external entitites with the system.System configuration:Identification and specification of the major physical components of the system.


Design aspects (2)System architecture:The system architectural model is driven mainly by system, not SW/HW, aspects.System usage:The design is driven by the needs of the system itself!System SW/HW structure:SW/HW solution independent of implementation techniques.


Design aspects (3)System and SW behaviour:Interactions between SW components and the outside world.Internal interactions between the SW components.Dynamical behaviour of the overall SW structure.Dynamical behaviour of individual SW components.


Design aspects (4)SW distribution:Operational and performance requirements (system responsiveness, safety, degradation and failure modes, test, commissioning and maintenance functions).Information concerning the execution times of individual objects.Timing data for inter-object communication activities.Network timing performance.


2. Practical diagramming methods


The major design techniquesStructured / data flow methods:Functional modeling (80s)Greatest CASE tool support for the Yourdon & SDL approaches. Object-oriented (OO) methods:Data&functional modeling (90s)The industry de facto standard: the Unified Modeling Language (UML).AADL, ACME, Wright, ADL.


DiagramsStructured designsContext diagramsEntity relationship diagramState transition diagrams...OO designsUse case diagramsDeployment diagramsPackagesClass diagrams...


What is a(n OO) model?An abstract model of a system:Defined by a set of (OO) diagrams.Contains a semantic backplane:i.e., a documentation, such as written use cases, that drive the model elements and diagrams.Its conceptual model (a computer program) attempts to simulate the abstract model.


Well-defined (OO)modelSelf-consistentPresents multiple levels of abstractionCompleteFacilitates communication among the various stakeholders Allows easy changes over time


What is a pattern?Pattern is more than a model.It is a three-part rule, which expresses a relation between:a certain context,a certain system of forces which occurs repeatedly in that context, and a certain SW configuration which allows these forces to resolve themselves. http://hillside.net/patterns


OO development process (1)OO analysis:Establish system requirements (problem analysis)Develop the ideal SW model and map it onto the HW architecture (structural & behavioural analysis & modeling)Develop the subsystem specification model (further object modeling)

OO design:For each processor develop the specification model (physical and interfacing aspects)For each processor develop the implementation model (concurrent SW)For each task produce its sequential code (code-related items).


OO development process (2)Spiral model ofa SW process(Boehm, 1988)Recognition of risks!http://www.answers.com/topic/spiral-model


The Rational Unified Process (RUP; IBM, 2003)Inception: establish a business case for the system.Elaboration: develop an understanding of the problem domain.Construction: system design, programming & testing.Transition: moving the system to the user community.


The Agile Unified ProcessA lite version of the RUP:


The historical development of UML (1)Previous efforts:OOD methods:Shlaer & Mellor, 1988Coad & Yourdon, 1990Abbott & Booch, 1991Jacobson, et al, 1992...Objects, types & classes


The historical development of UML (2)Rational Software Corporation, 1994Unified Method:Rumbaugh - OMT (OOA)Booch (OOD)Jacobson Objectory (OOSE)OMG (Object Management Group), The UML specification, 1996 UML1.1, 1997The Three AmigosRumbaughBoochJacobsonhttp://cs-exhibitions.uni-klu.ac.at/index.php?id=185


The main characteristics of UMLGraphical (object) modeling language for complex systems:Specification, design, automatic code generation, documentation.

Relatively easy to learn (intuitive)Well-defined (models can be verifiable)Independent of any programming languageGreat CASE tool support


What does UML include?Model elements, that capture the fundamental modeling concepts and semantics.A notation, for visual rendering of model elements.Rules, that describes idioms of usage.It also provides extensibility and specialization mechanisms to extend the core concepts.


Model elementsAll fundamental concept:From concrete language constructs (class).To abstract concepts (use case ). Sample designDesign mirrored in the UML semantics model


The structure of UMLUML diagrams represent three different views of a system model:Functional requirements viewStatic structural viewDynamic behaviour viewWarning: UML is a notation and NOT a methodology!


Functional requirements viewEmphasizes the functional requirements of the system from the user's point of view.Includes:Use case diagrams:WHY system is used in WHO uses it!


Functional requirements view13 types of diagrams what must happen in the system


Static structural viewEmphasizes the static structure of the system using: objects,attributes,operations,relationships.Includes:class diagrams (objects, packages, actors),composite structure diagrams.


Static structural view13 types of diagrams what things must be in the system


Dynamic behaviour viewEmphasizes the dynamic behavior of the system by showing collaborations among:objects and changes to the internal states of objects.Includes:sequence diagrams,activity diagrams,state machine diagrams.


Dynamic behaviour view13 types of diagrams the flow of control and data among the things in the system


Structural elements & diagramsObjects, classes (structured classes, ports), and interfacesRelations (association, generalization, and dependency)Subsystems, components, and packages


Objects, classes, and interfacesObject: a run-time entity that occupies memory at some specific point in time:Has behavior (methods) & data (attributes)Class: a design-time concept that defines the structure and behavior for a set of objects to be created at run-time:Specifies behavior (methods) & data (attributes)Interface: a design time concept that specifies the messages a class receives:Has behavior only (operations)


RelationsPrimary Relations in UMLAssociationsNormal associationAggregationCompositionGeneralizationDependency for templates for classes and for use cases. . .


Relations


Packages and subsystemsLarge-Scale Logical DesignPackages capture larger scale decompositions that exist at design time (cannot be instantiated).Packages organize your model.Packages define a namespace for managing large numbers of model elements.Large-Scale Physical DesignSubsystems capture larger scale decompositions that exist at run-time.Contains objects that collaborate to realize common function purpose (use case) of the subsystem.


SubsystemsProvides opaque interfaces to its clients and achieves its functionality through delegation to objects that it owns internally.Contains components & objects on the basis of common run-time functional purpose.Metasubtype of both Classifier & Package.SystemSubsystem


ComponentsBasic reusable element of software:Organizes objects together into cohesive run-time units that are replaced together.Provides language-independent opaque interfaces.


Behavioral elements & diagramsActions and activitiesOperations and methodsActivity diagramsStatechartsInteractionsUse case and requirements models


UML diagram type usage (1)Use case:Capture requirements in terms of interactions between a system and its users.Class:Shows classes, attributes, associations and generalization.Object:Shows selected instances of classes and values for attributes at run time.Sequence:Shows synchronous and asynchronous interactions between objects.State Machine:Shows behavior over time in response to events.


UML diagram type usage (2)Component:Shows large-scale components and their interfaces.Composite Structure:Shows internal structure, ports, collaborations, structured classes.Package:Shows groupings of elements into packages and dependencies between them.Communication:Shows communications between objects (used to be called collaborations).


UML diagram type usage (3)Activity:Shows parallel and sequential behaviors connected by data and control flows.Interaction:Shows an overview of activities and interactions.Timing:Shows timing in a variation of sequence / interaction diagrams.Deployment:Shows deployment onto nodes in a specific implementation.


OO analysis (1)A number of UML techniques can come handy here:Use casesA class diagram drawn from the conceptual perspective.An activity diagram to show the work flow of the organization.A state diagram, which can be useful if a concept has an interesting life cycle.


OO analysis (2)Analysis of RT & E systems:SchedulabilityScheduling policyReliabilityConcurrent tasksSafety & impact of component failureGraph theory for dependence modeling


Use case diagram


OO designUseful UML design techniques:Class diagrams from a SW perspective.Sequence diagrams for common scenarios.Package diagrams to show the organization of the SW.State diagrams for classes with life histories.Deployment diagrams to show the physical layout of the SW.


Sequence diagram


UML for ESsInitially not designed for real-time:UML Profile for Modeling Quality of Service and Fault Tolerant Characteristics and Mechanisms;UML profile for schedulability, performance and time (MARTE).UML 1.4Real-Time UML (UML-RT ROOM) is standard UML (2.0).

Allows you to:work at a higher level of abstraction;visualize concurrent behavior.25 % of RT&E projects in 2007 were using UML (Venture Data Corporation).


UML profiles What is a profile? A UML model, which describes extensions and subsets to UML;the OCL (Object Constraint Language) and stereotype definitions that describe the rules, which in UML 2, are captured in a package.


UML Profile for Modeling Quality of Service and Fault Tolerant Characteristics and Mechanisms

http://www.omg.org/docs/ptc/04-09-01.pdfDefines stereotypes for properties, such as:performance, dependability, security, integrity, coherence (temporal consistency of data & SW elements), throughput, latency, efficiency, demand, reliability, and availability.


UML profile for Modeling and Analysis of Real-Time and Embedded systems

MARTEAdds capabilities for analyzing schedulability & performance properties of UML specifications.Three main packages:Time & concurrent resource modeling packageReal-time & embedded application modeling packageReal-time & embedded application analysis


RT Profile


Additional diagrams for RT systemsSystem configuration diagramsSystem architecture diagramsSystem scope diagramsNode architecture diagramsProcessor architecture diagramsMemory map diagramsTasking diagrams


ConcurrencyConcurrency architecture refers to:Identification of task threads and their propertiesMapping of passive classes to task threadsIdentification of synchronization policiesTask scheduling policiesUnit of concurrency in UML is an active object:active objects aggregate passive semantic objects via composition and delegate asynchronous messages to them.Standard icon is a class box with heavy line.


Tasking diagramClass diagram that shows elements related to the concurrency model: active objects, semaphore objects, message & data queues, constraints & tagged values.May use opaque or transparent interfaces.


EU Project MARTES


Textbooks about UMLDouglass, B. P. (2002). Real-Time Design Patterns: Robust Scalable Architectures for Real-Time Systems, Addison-Wesley.Douglass, B. P. (2007). Real-Time UML Workshop for Embedded Systems, Elsevier-Newnes.Fowler, M. (2003). UML Distilled Third Edition, Addison-Wesley.Ambler, S. W. (2004). The Object primer Third Edition, Agile Model-Driven Development with UML 2.0, Cambridge University Press.


How to select a UML tool?Repository SupportHTML documentationPick lists for classes & methodsVersioningPrinting supportExporting diagramsRobustnessNew ReleasesRound-Trip engineeringFull UML 2.x supportData modelingModel navigationDiagram viewsScriptingPlatformIn the future ...


List of UML toolsMS, Visio 2002 ProfessionalRhapsody, TelelogicBridgePoint UML Suite, Mentor Graphicshttp://www.objectsbydesign.com/tools/umltools_byPrice.html ($ 11,500- $ 0)


3. Designing and constructing software


Design & construction methodsMonolithic (great design plan implementation):When one person is concerned with the design & build programme.For simple tasks.Modular (modular design plan design integration implementation):Pros: Subtasks are handled simultaneously by different designers.Cons: changes to the global values can produce design chaos.Independent or model-based (modular design plan modular design implementation integration)


Modular design & construction


Model-based design & construction


Three ways of using UMLSketch - UML is used informally (Fowler): Few diagrams are sketched out and discussed, coding proceeds directly.Blueprint - UML is used to specify the SW structure (Powell): A tool can generate code frames from these models. The developer then adds code directly to the model.Warning: One-to-one correspondence between the UML diagrams and the code!Executable - UML is used as a programming language:The UML action model is designed to allow the model to be translated into any implementation.


The evolution of development


Approaches to using UML as a programming languageModel Driven Architecture, MDA (Kleppe, et al.):Build platform-independent model (PIM).Tools can turn a PIM into a platform-specific model (PSM).Further tools generate code from that PSM.

Executable UML (xtUML, Mellor and Balcer):Build platform-independent model.Use a model compiler to turn that UML model into a deployable system in a single step.Skeleton code executable code


MDA(OMG standard)Formal specs of the systems structure & functionPIM + technical details, such as middleware, OS, network, CPU characteristics


The model is the embedded codewith state machines for modeling concurrent behavior and exploring synchronization issues


xUML


How to use the xUML? (1)System ModelDomain identificationDefining use casesIterate the system modelModeling a single domain ClassesState machines one for each classProcedures one per each state machineIterating the domain model abstract the classes by modeling one role per classIterating between domain and system model


How to use the xUML? (2)Verification and executionModel verificationStatic like a syntax checkDynamic requires real objects and a scenario to executeModel compilationxUML implementationDrawback: no non-functional requirements: QoS, concurrency!Iterating verification and executionNucleus BridgePoint


Project failures usually occur whenExecutable models are not employedCode is allowed to deviate from the modelsDevelopment processes dont manage risks through early validation


Choosing a programming language for ESsAda 95: OO version in 1995; for safety-critical applicationsC:MISRA-C for safety-related systemsUsed by 77 % of projectsC++:OO language; it is NOT an extended CUsed by 44 % of projectsEmbedded C++:a subset of C++.Java


Implementation and performance issues Analysing and testing source codeMission-critical and safety-critical systemsPerformance engineeringDocumentation


1. Analysing and testing source code


SW source code test techniquesSW source codetestingAssessment of source code qualityAssessment of source code behaviourSW source analysis(static analysis)SW code execution(dynamic analysis)CodeexecutionCodeinspection


Types of testing


Integrated development & testing


Black-box testing


UML & testingOne objective of the UML 2.0 is executable UML (xUML) meaningCode generationSimulationValidationTest generationUML testing profile


UML testing profile


2. Mission-critical and safety-critical systems


Critical systemsSystem in which failure(s) may have significant and far-reaching consequences:Mission-critical: telecommunication switchSafety-critical: airbag deployment system

Fault = errorFailure = numerical overflow, wrong number computed ...


How to prevent failures?

Formal specifications using formal specification languages (e.g. VDM)Basic design & programming issues!

Dealing with run-time problems:Exception handlingBackward error recoveryN-version programmingReal-world interfacingOSsProcessor problemsHW-based fault tolerance


3. Performance engineering


Why performance engineering is important?In most projects functional designs ARE correct.However, RT & E SW design is intrinsically driven by the need to meet system time requirements.Major categories of system timing requirements:Control loopsAlgorithmicprocessingHuman factorsComputationalprocessingResponsedeadlines


Ways of performance modelingTop-down requirements-driven:Design performance: Who knows!Bottom-up results-driven:Based on using known data to predict system performance.Middle-out risk-driven:Performance modeling is all about risk reduction in general.


Some practical issues in performance engineeringBasic questions: What? Why? How the results will be used? Which modeling techniques are best suited to the problem?How much is it going to cost in manpower, time & money? Modeling & simulation options:Simple calculations (deterministic)Spreadsheet analysis (deterministic)Modeling tools (non-deterministic / deterministic):Simprocess (graphical modeling tool)Simscript (language-based tool)5 % of the project costs


4. Documentation


DocumentationWhy documentation is necessary?Documentation structure:Basic questions: What? Who? When?Extend of supplyCommercial plan & costingProject plan & management structureQuality planOverall technical description


Overall technical descriptionOverall system conceptsSystem design philosophySystem functional descriptionEquipment (HW) descriptionSW structureSW design techniquesSystem performance featuresTesting & installation techniquesMan-machine interfacingMaintenance & repair techniquesReliability estimatesFailure mode behaviour


SW life-cycle documentationRequirementsphasesDesignphasesImplementationphasesTest, integration &debug phasesSystemfunctionalspecificationsSWsystemspecificationssourcecodelistingsSWtestdocumentsSWapplicationdocumentsSWinstallationdocuments


System functional specificationsSystem functionalspecsBlock diagramdescriptionFunctional diagramdescriptionRequirementsspecificationsOverallsystemdescriptionSubsystemdescriptionsFunctionalblockdiagramsControlschemesNon-functionalrequirementsFunctionalrequirementsDevelopmentrequirements


SW system specificationsSystem systemspecsArchitecturalstructurePhysicalstructureSystem levelSubsystem level System structure System inputs & outputs System dynamics system timing System protection Subsystem structure Logical processes Process interfaces Process communication Process synchronizationSystem levelTask level Process models Process scheduling Process timing Process sychronization Process housekeeping & synchronizationTask (program structure)


Organization (1)Consultation: JSI / room S6D, (01) 4773-363, [email protected] Web page (course material): csd.ijs.si/korousic/korousic.html


Organization (2)Course textbooks:J. Cooling, Software Engineering for Real-Time Systems, Addison-Wesley, 2003;I. Sommerville, Software Engineering, Addison-Wesley, 2004.


Organization (3)Course material: slide copies, books, papersExam: seminar work OR oral examMay, June, September


Organization (3)Ideas for seminar works:Comparison of programming languages (xUML)Model-driven developmentSysML/UML for embedded systemsOpen-source Eclipse platform (UML 2.x metamodel), http://www.eclipse.orgDomain-specific modelingReverse-engineering


Pozdravljeni, pred nami je sklop tirih ur, v katerih bom na hitro preleteli vsebine pomembne za kakovosten razvoj vgrajenih sistemov v realnem asu. Prepriana sem, da je problematika, ki jo bomo obravnavali v dananjem predavanju, zanimiva in pomembna tudi za razvijalce drugih raunalnikih sistemov.

Ker se bomo v dananjem predavanju omejili na razvoj programske opreme, vsekakor pa je pomemben tudi razvoj strojne opreme, sem povabila kolega T.B. In G.P. da vam predstavita slednjo problematiko v dveh seminarjih, ki jih bomo pripravili v tem semestru, najkasneje do maja. O natannih datumih seminarjev vas bom pravoasno obvestila.

Predlagam, da poteka predavanje na obiajen nain, tirikrat po 45 minut. Lahko pa tudi zdruimo po dve uri in imamo vmesni odmor malce dalji.Morda je pomembno, da osveimo glavno sporoilo jesenskega predavanja, na katerem smo obravnavali znailnosti vgrajenih sistemov za delo v realnem asu. Vgrajeni sistemi so postali prevladujoi med sistemi, ki nas vsakodnevno obkroajo, eprav se jih morda niti ne zavedamo. Imajo lahko zelo enostavno ali zelo kompleksno strukturo, za vse pa je znailno, da morajo delovati v realnem asu. Njihova oprema mora biti razvita tako, da omogoa prilagajanje zahtevam v realnem asu, zanesljivost delovanja v izrednih razmerah, prenosljivost v druga okolja, vkljuitev posameznih modulov v razline sisteme (reusability), menjavo posameznih modulov v alternativnimi ali nadgradnjo z novimi moduli itd., saj se vgrajeni sistemi s asom lahko spreminjajo. Morda je pomembno, da osveimo glavno sporoilo jesenskega predavanja, na katerem smo obravnavali znailnosti vgrajenih sistemov za delo v realnem asu. Vgrajeni sistemi so postali prevladujoi med sistemi, ki nas vsakodnevno obkroajo, eprav se jih morda niti ne zavedamo. Imajo lahko zelo enostavno ali zelo kompleksno strukturo, za vse pa je znailno, da morajo delovati v realnem asu. Njihova oprema mora biti razvita tako, da omogoa prilagajanje zahtevam v realnem asu, zanesljivost delovanja v izrednih razmerah, prenosljivost v druga okolja, vkljuitev posameznih modulov v razline sisteme (reusability), menjavo posameznih modulov v alternativnimi ali nadgradnjo z novimi moduli itd., saj se vgrajeni sistemi s asom lahko spreminjajo. Danes bomo pregledali koncepte nartovanja, razvoja in testiranja, ki jih je smiselno upotevati pri delu z vgrajenimi sistemi. Moram poudariti, da je tematika zelo obirna in lahko v tako kratkem asu le preletimo kljune vidike, razumeli jih boste, ko jih boste vkljuili v svoje delo. Morda prvo izkunjo lahko pridobite v seminarju, ki vam ga toplo priporoam. O literaturi in idejah za seminarske naloge se bomo pogovorili na koncu predavanja. V prvem delu bomo obdelali pomen nartovanja sistemov s pomojo diagramov, preleteli bomo zmogljivosti jezika za modeliranje sistema, kot je UML.Vpraanje: Izvorna koda temelji na zapisu, ki je bolj formalen od pogovornega. Zakaj se vseeno pojavijo napake v kodi?

Kot iztonico si oglejmo poenostavljen postopek razvoja vgrajenih sistemov v preteklosti. Programerji so si zamislili problem, ki so eleli reiti. Zapisali so ga v obliki programa (kode). Le-to so testirali in po potrebi prilagodili. Dokumentacija je bila podana v obliki izpisa izvorne kode. V najboljem primeru so v zaetni fazi problem ilustrirali v obliki diagrama poteka stanj (flow diagrams). Taken pristop je za seboj povlekel niz napak in tudi usodnih posledic. V preteklosti ni bilo ostre lonice med programerji in nartovalci sistema.

Statistini podatki govorijo o dejstvu, da storimo 50 % resnih napak e v fazi nartovanja in le 25 % v razvojni fazi. Iz tega sledi, da se moramo resno osredotoiti na problem modeliranja, e se elimo izogniti resnejim napakam, ki so v vgrajenih sistemih lahko tudi usodne.Danes poznamo niz orodij za nartovanje programske opreme, ki podpirajo delo z diagrami oziroma omogoajo kakovostno modeliranje sistema z diagrami. Zanimivo je, da se potreba po taknih orodjih ni pojavila v akademskih krogih, temve v industriji in komerciali.

Osnovna definicija diagrama: to je grafina (vizualna) predstavitev abstraktnega modela sistema, ki omogoa obravnavo sistema z razlinih vidikov. Problem laje prepoznamo, ga razbijemo na podprobleme, sledimo spremembam, uredimo dogodke v sistemu in zgradimo scenarije za posebne razmere.Diagrame lahko uporabimo na ve nainov, kot orodje za nartovanje in vzdrevanje sistema, medij za komuniciranje ali tehniko dokumentiranja. Z diagramom doloimo abstraktni model sistema in preverimo, ali model ustreza kontekstu sistema.

Pri razvoju vgrajenih sistemov sodeluje ve ljudi: uporabniki, nartovalci in vzdrevalci sistema med delovanjem. Tudi pri razvoju zelo enostavnih sistemov ne smemo pozabiti, da je dokumentacija pomembna v zaetni fazi, ko sistem analiziramo in nartujemo, med razvojem, pri testiranju in v konni fazi, pri vzdrevanju sistema (str.371).

Heres the design package for a household setback thermostatPri dokumentaciji je zelo pomembno, da obravnavamo sistem na obeh nivojih, globalnem in lokalnem. Najprej moramo problem razdelati in ele nato iskati reitve za podprobleme.

Ko izdelujemo diagrame z namenom vzdrevanja sistema, moramo upotevati, da bodo te diagrame uporabljali ljudje, ki niso sodelovali pri razvoju sistema, ki ne bodo natanno poznali sistema, bodo potrebovali veliko informacij za delo na manjem modulu sistema.

Statistini podatki govore o 50 % deleu strokov, ki jih vzdrevalci porabijo za odkrivanje delovanja sistema!

Seveda je pomembno, kako izdelamo model oziroma katere informacije nosijo posamezni diagramu. Izdelajmo majhne, enostavne, jasne, popolne diagrame s im manj abstraktnih simbolov. Uporabljajmo formalna pravila, sicer diagram ne bo jasen in s tem neuporaben! Glavni namen diagrama je vzpostaviti vez med dvema kljunima pogledoma na sistem: kaj elimo dosei (problem) in kako bomo to izvedli (reitev). Diagram se mora osredotoiti na problem in ne na reitev.

Pri nartovanju je pomembno, da diagram vsebuje elemente, ki omogoajo vpogled, oceno in obravnavo sistema, ki ga diagram ponazarja. V fazi modeliranja ni lonice med strojno in programsko opremo.

Velikost: A2-A4Enostavnost: str.375Trenutno ne obstaja vrsta modela, ki bi omogoala modeliranje sistema z vseh vidikov hkrati. Sistem ima veliko vidikov, ki jih lahko ponazorimo le s pomojo razlinih diagramov.

Ko ponazarjamo kontekst sistema, moramo opredeliti vse zunanje entitete (naprave, uporabnike, mrene povezave itd.), lastnosti entite (parametre senzorjev, obmoja, natannost...) in povezave med entitetami.Konfiguracija: identifikacija in specifikacija fizinih komponent.Govorili bomo o metodah za izdelavo diagramov in ne o metodah nartovanja, saj lahko prve uporabimo pri razlinih metodah nartovanja.V nadaljevanju se bomo osredotoili na praktine metode za izdelavo diagramov in glede na trenutno stanje/trend v industriji bomo dali poudarek na objektno-orientirane pristope. Omejili se bomo na UML notacijo, ki postaja de facto standard v industriji.Za obutek kompleksnosti diagramov si oglejmo skupini diagramov, ki jih obiajno uporabljamo pri prvi ali drugi metodi. Ne prva ne druga metoda nartovanja ne omogoata idelanega modeliranja sistemov v realnem asu.

Do zdaj smo govorili o diagramih, katerih skupek je abstraktni model sistema. Vkolikor uporabljamo OO diagrame, govorimo tudi OO modelu. Abstraktni model pa vsebuje poleg diagramov tudi t.i. metamodel, ki predstavlja semantino nadgradnjo sistema, praktino je to dokumentacija, ki vsebinsko povezuje posamezne elemente oziroma diagrame sistema in jih opisuje.

Abstraktni model lahko prevedemo tudi v konceptualni model, ki omogoa simulacijo sistema oziroma abstraktnega modela.Podobno kot diagrami, mora biti tudi model primerno izdelan, venivojski, popolen, mora omogoati komunikacijo med udeleenci...Predno nadaljujemo z opisom metode nartovanja oziroma postopka izdelave diagramov, obdelajmo e pojem vzorca, ki se pojavlja v povezavi z modelom. Kot prvo, vzorec ni model, temve ocena modela. UML narekuje izdelavo modela, medtem, ko ga vzorec ocenjuje. Vzorec mora identificirati problem, razloiti reitev in okoliine, pri katerih vzorec deluje dobro ali slabo.

TemplateKer nas UML vodi pri modeliranju sistema na nivoju analize in nartovanja sistema, najprej osveimo faze posameznih faz. Pri analizi opredelimo zahteve po delovanju sistema, izeldamo model SW in ga mapiramo na HW ter izdelamo specifikacije podsistemov.Nato pri nartovanju izdelamo za vsak process model specifikacije, ga izdelamo in generiramo kodo opravil.Postopek nartovanja zgleda enostaven, vendar je pomembno, da ga izvedemo na preudaren nain. UML temelji na pilnem modelu, ki ga je doloil Boehm pred 20 leti. Kljuna lastnost tega modela je detekcija rizikov in nartovanje scenarijev za njihovo prepreevanje oz. odpravo. S tem prihranimo na asu in denarju.Iterativni postopek izdelave diagramov z UML, ki izhaja iz piralnega modela, imenujemo tudi RUP. Le-ta je sestavljen iz 4 faz, ki v ve iteracijah izvajajo naloge, kot so modeliranje, detekcija zahtev, analiza... V prvi fazi postavimo model, v drugi problem dojamemo, v tretji poiemo reitev in v etrti reitev prenesemo v realno okolje. Ta proces temelji na praksi iz industrije.Medtem ko je RUP v uporabi pri nartovanju vejih projektov, je njegova lite razliica v uporabo pri manjih projektih. 4 faze v ve iteracijah opravijo manj nalog.UML je revolucionaren plod veletnega dela na podroju OO analize in nartovanja. Omenimo nekaj kljunih imen in notacij izpred 20 let. V zaetku 90. so bili nosilci ideje o podatkovnem modeliranju v manjini v primerjavi z nosilci ideje o funkcionalnem modeliranju.UML so razvil 3 osebe, zato se imenuje Unified. RSC (zdaj del IBM) je leta 94 najel Rumbaugh, ki je bil ekspert na podroju OOA. Z Boochom in Jacobsonom so v olnih razpravah prili do konsenza in objavili specifikacijo industrijskega standarda UML leta 1997. Predlagali so zdruenju OMG, ki e danes podpira UML. Trenutno uporabljamo verzijo UML 2.0, ki je za razliko od predhodnih verzij 1.3 industrijski standard.UML ni programski jezik, ni CASE orodje in ni metoda za nartovanje, temve vkljuuje elemente, notacijo in . Omogoen pa je prehod v ve programskih jezikov in veliko CASE orodij podpira UML.

Sistem modeliramo tako, da upotevamo razline, komplementarne, vidike sistema. Sistem moramo razumeti in obravnavati z vidika funkcionalnosti, strukture in dinaminega obnaanja. Ravno to je znailno za OO metode nartovanja, ki nadgrajujejo nartovanje sistema z vidika funkcionalnosti s podatkovnim. Vendar ne smemo pozabiti, da je UML le notacija in ne metodologija!Pri obravnavi funkcionalnosti sistema upotevamo vidik konnega uporabnika sistema in razvijalca oziroma programerja. Najbolj znailen diagram, ki ga uporabimo v ta namen, je Use case diagram. S tem diagramom prikaemo zakaj uporabljamo ta sistem in kdo ga uporablja doloimo requirements!UML podpira 13 razlinih diagramov, ki jih lahko uporabimo za modeliranje sistema. Nartovalci lahko sami naredijo izbor diagramov, ki jih potrebujejo v doloenem projektu. Nekateri trdijo, da lahko 80 % projektov kakovostno modeliramo z 20 % diagramov UML.

Use case diagram sodi med t.i. behaviour diagrame, ki opisujejo obnaanje sistema.Pri modeliranju sistema z vidika strukture sistema obravnavamo statino strukturo sistema, ki se s asom ne spreminja. Tu so pomembni elementi, kot so objekti, njihovi atributi, operacije oz. metode in povezave med elementi. Statino strukturo sistema lahko opiemo s class diagrami in composite structure diagrami.Ta dva diagrama lahko dopolnimo e s tirimi diagrami, kot so component, object, deployment in package diagram. Obravnavamo zlasti vpraanje, zakaj so doloeni (fizini) elementi, ki vkljuujejo tudi uporabnike, potrebni v sistemu. Gre za modeliranje fizine arhitekture sistema. Package je zelo enostaven element, ki povezuje ostale elemente, lahko tudi pakete. Pomembne so zlasti relacije oziroma odvisnosti med paketi povezujejo elemente, ne sporoajo pa, kaj se zgodi pri vzpostavitvi povezave.

Podrobnosti bomo obdelali kasneje (v naslednji uri?).Pomemben je e tretji vidik sistema, dinamino obnaanje, kjer moramo razdelati relacije med objekti in situacije, v katerih le-ti spreminjajo interna stanja. Znailna diagrama iz te skupine sta sequence in state machine diagram. Activity diagram je kombinacija flow-charts in state machines.Seveda lahko tudi ta dva dopolnimo s communication, interaction in timing diagrami, kar je e zlasti pomembno pri real-time in embedded sistemih. Obravnavamo zlasti vpraanje pretoka nadzora in podatkov med elementi v sistemu.Ponovimo, sistem modeliramo s funkcionalnega (structural) in podatkovnega (behavioral) vidika: zanima nas tako struktura kot tudi obnaanje sistema v realnem asu. Najpomembneji elementi, s katerimi v diagramih ponazarjamo strukturo sistema so objekti, razredi in povezave med njimi; relacije; ter podsistemi, komponente in paketi. Ker so to pojmi, s katerimi se ves as modeliranja z UML sreujemo, ji na kratko opiimo. Objekti je run-time entiteta, ki je doloena z metodo (tako opiemo njeno obnaanje) in podatki (ali tudi drugae reeno, atributi) ima avtonomijo. Lahko je SW, HW, mehanini, kemijski ... element.Razred je koncept, ki doloa strukturo in obnaanje mnoice objektov, ki ivijo v run-time. Objekt je instanca razreda!

Povezava je koncept, ki doloa sporoila, ki jih razred sprejema opisan je z operacijami.

Obstaja ve nainov opisa objekta. Lahko ga doloimo z imenom, razredom, kateremu pripada in elenimi vrednostmi atributov. Relacije omogoajo povezave med elementi v run-time! To so lahko asociacije, posploitve in odvisnosti. Z asociacijo poveemo dve instanci razredov.Paketi povezujejo ve elementov skupaj, lahko tudi pakete. S paketi laje organiziramo strukturo sistema. Za razliko od podsistemov, ki jih uporabljamo pri modeliranju fizinega sistema v run-time, uporabljamo pakete pri modeliranju loginega sistema.Morda posvetimo e nekaj besed podsistemom: vsebujejo komponente in objekte.Kaj so komponente? To so reusable elementi programske opreme.Kateri so pomembni elementi in diagrami, s katerimi opiemo obnaanje modela: akcije, operacije in diagrami... Opise diagramov lahko najdemo v prironiku ali tutorialu, na namen je le da se seznanimo z raznolikostjo UML notacije, ki zagotavlja obravnavo sistema z razlinih vidikov. Tudi Jimova knjiga lepo opisuje diagrame in njihovo uporabo pri modeliranju real-time in embbeded sistemov.Na hitro preletimo osnovni pomen/namen diagramov, ki smo jih omenili.Kot sem danes e nekajkrat omenila, si lahko sami naredimo izbor diagramov, obstaja le nekaj splonih napotkov za tiste, ki se morda z UML sreujejo prvi. Spomnimo se na RUP in AUP, kjer smo strukturirali postopek izdelave sistema. Pomembni fazi sta analiza in nartovanje sistema. Poglejmo si sploen napotek za uporabo diagramov v fazi OO analize sistema. Smisleno je modelirati sistem z use case, class diagramom itd.Primer use case diagramaNartovanje sistema izvedemo ...Primer sekvennega diagramaGlede na to, da nas zanima modeliranje sistemov v real-time in embedded, spregovorimo e o specifiki UML za tovrstne sisteme. Prvotno UML ni bil nartovan za uporabo pri teh sistemih. K srei pa je bil tako zasnovan, da dopua enostavno raziritve s t.i. Profili. e to, OMG standari so naporni za branje. Pomembna sta dva profila, ki sta vkljuena v t.i. Real-Tme UML, ki je danes standard. Omogoa abstrakcijo sistema na vijem nivoju in vizualizacijo soasnega obnaanja. Po virih Venture ... je bilo leta 2007 25 % vseh projektov izvedenih v UML!Kaj je profil?OCL - a formal language used to describe expressions on UML models. These expressions typically specify invariant conditions that must hold for the system being modeled or queries over objects described in a model. Note that when the OCL expressions are evaluated, they do not have side effects (i.e., their evaluation cannot alter the state of the corresponding executing system). OCL expressions can be used to specify operations / actions that, when executed, do alter the state of the system. UML modelers can use OCL to specify application-specific constraints in their models. UML modelers can also use OCL to specify queries on the UML model, which are completely programming language independent.

Pomemben profilProfil je zajet v treh profilih.Pri obeh metodah lahko diagrame dopolnimo z diagrami iz te mnoice.Configuration: fizina povezava HW s sistemomArchitecture: povezava funk. Enot znotraj sistemaScope: nadgradnja kontekstnega diagrama z uporabniki; natanno doloimo meje sistemaNode architecture: prikazuje osnovna raunska in komunikacijska vozliaProcessor architecture: HW izvedba vsake procesorske enoteMemora map: v E sistemih je kombinacija memory stage devices; all physical addresses are located at specific memory addressesSoasnost pomembno pri multi-tasking sistemihTask diagram to je zadnja stopnja pred kodiranjemZanimiv evropski projekt, ki zdruuje dva vidika razvoja sistema. O drugem bo govoril Gregor.LiteraturaKako izbrati orodje?The tool should allow you to pull in only the components that you want from another model, without having to import the entire model. The ability to both forward and reverse engineer source code (Java, C++, CORBA IDL) Seznam razpololjivih orodij.Ko smo analizirali in zasnovali sistem, ga moramo e razviti. Kako nam v tej fazi slui UML?Ker statistika pravi, da izhaja 50% napak iz faze nartovanja sistema, je ta faza zelo pomembna. Skozi as se z izkunjami postopek nartovanja spreminja od monolitskega, kjer oseba naredi nart in izvedbo sama, modularnega, kjer nartujemo posamezne logine enote loeno in jih razvijamo integrirano do t.i. neodvisnega, kjer uporabimo modluarnost v vseh fazah razvoja sistema in posamezne module zdruimo v zadnji fazi. Ni tesne povezave med nartovalci in razvijalci. Tudi HW se razvija loeno od SW.Kako lahko vkljuimo UML v fazo razvoja sistema?Neformalno, kar pomeni, da uporabimo UML za izdelavo nekaterih diagramov, ki sluijo za debato kodiranje sledi direktno.Blueprint z UML doloimo diagrame in metamodel, ki ga prevedemo z orodjem v kodo. Moramo biti previdni!UML lahko uporabimo kot programski jezik.Graf ponazarja evolucijski razvoj postopka razvoja sistema. Slii se super, vendar...Dva pristopa: MDA in e-UMLMDA 3 stopnjee-UML 2 stopnji, to je v osnovi UML brez semantino ibkih elementov, ki podpira semantino mono dinamikoPodatke in obnaanje natano opiemo, z upotevanjem pravil.Sistem lahko obravnavamo na vijem nivoju abstrakcije.S vsakim state machine diagramom opiemo en proces. Funkcionalnost sistema preverimo pred konno izvedbo.Super za obiajne aplikacije, pri RT in E aplikacijah moramo biti pozorni na dejstvo, da ne omogoa specifikacijo nefunkcionalnih zahtev.Izkunje izkuenih: super, vendar stane veliko tako orodje kot tudi izobraevanje!RealnostPrehajamo na drugi sklop tem, ki jih bomo zaradi pomanjkanja asa preleteli zelo na hitro, etudi so izrednega pomena.Pri RT in E sistemih je zelo pomembno, da obravnavamo sistem z vidika funkcionalnosti kot tudi dinaminega vidika obnaanja. Tako pri testiranju preverjamo kakovost kode in pravilnost obnaanja kode. Opraviti moramo statino analizo in dinamino slednji s simulacijo kode.RT in E sistemi so pogosto tudi kritini sistemi, mi se bomo verjetno sreevali preteno s sistemi, ki morajo zagotavljati visoko varnost. Moramo loiti med napako in odpovedjo pravilnosti sistema (polomija) zaradi napake v sistemu.Kako se izogniti polomiji? Uporabljajmo jezik za formalno specifikacijo.UML je risk-driven

Documents

Real-Time Embedded Systems