uml â€“ unified modeling language

UML – Unified Modeling Language

• Behavior diagrams: Use case diagram• Use cases diagram basically are a substitute of the requirements being

Modeled into the architecture. The external viewpoint as to “what” the System should do rather “how”

/ Faculteit Wiskunde en Informatica PAGE 018-10-2011


• Behavior diagrams: Activity diagram• Activity diagrams are used to model the behaviors of a

system, and the way in which these behaviors are related in an overall flow of the systemy

• The logical paths a process follows, based on various conditions, concurrent processing, data access, interruptions and other logical path distinctions are all usedinterruptions and other logical path distinctions, are all used to construct a process, system or procedure



• Behavior diagrams: Activity diagram



• Behavior diagrams: State Machine diagram• A State Machine diagram illustrates how an element, often a class, can move

between states classifying its behavior, according to transition triggers, constraining guards and other aspects of State Machine diagrams that depict and explain movement and behavior



• Interaction diagrams: Sequence diagram• Sequence diagram is an interaction diagram that details how operations are

carried out -- what messages are sent and when

• Sequence diagrams are organized according to time expressed in the ti l d l th ti l lsequential order along the vertical plane



• Interaction diagrams: Sequence diagram



• Interaction diagrams: Communication/Collaboration diagram• Communication diagram shows the interactions between elements at run-

time in much the same manner as a Sequence diagram. Communication diagrams are used to visualize inter object relationships• Communication diagrams are used to visualize inter-object relationships, while Sequence diagrams are more effective at visualizing processing over time



• Interaction diagrams: Communication/Collaboration diagram



• Interaction diagrams: Timing diagram• Timing diagram defines the behavior of different objects within a time-scale• Provides a visual representation of objects changing state and interacting

over time. Used for defining hardware-driven or embedded software componentsp


SysML

• SysML was identified as the key modeling language y y g g gthat could integrate the disparate tools sets that Systems Engineering use for a single project across various domainsvarious domains

• The idea behind it was that it would do the same trick for the Systems Engineering field as UML did for the loads of modeling languages in Software Engineering


SysML

Design principles:

1. Reuse – Reuse of UML 2.0

2 L i S ML k t i l t UML2. Layering – SysML packages as extensions layer to UML meta model

3 Extensibility – It offers the same extension mechanism as3. Extensibility It offers the same extension mechanism as UML (meta classes, stereotypes, model libraries)

4. Interoperability – SysML is aligned with the semantics of ISO AP 232 XMI i UMLISO AP- 232, same as XMI in UML


SysML

Package hierachy:


SysML

• Structural constructs: Class diagramg• Dependency Set added to group dependency relationships


SysML

• Structural constructs: Assembly diagramy g• Capability to model systems as tree of modular components. Can be used

throughout the development process multiple times


SysML

• Structural constructs: Parametric diagramg• Parametric models are analysis models that define a set of system

properties & parametric relationships among them• Used essentially with assembly level diagram• Time can be modeled as a additional property & other properties

may depend on it


SysML

• Structural constructs: Parametric diagramg


SysML

• Behavorial constructs: Activity diagramy g• Extensions to UML2

1 Control as Data:1. Control as Data: − Control can disable the actions that are executing− Transform its inputs to produce an output to control other actions

2. Continuous systems:y− Any sort of distributed flow of information & physical items through

system− “Nobuffer” and “Overwrite” features added

3 P b bilit3. Probability:− Edges which have probabilities associated for the likelihood of values

traveling on an edge


SysML

• Behavorial constructs: Activity diagramy g


SysML

• Cross cutting constructs: Requirements diagramg g• Requirement may specify a function, a system must

perform/performance condition a system must satisfy• Formalized to connect to other modeling elements (itself, analysis,

design, testing and implementing elements)• Type of modeling element can be controlled by using the

requirement diagramR i t h it t h t bl l• Requirement may have its own property, hence computable value not only text


SysML

• Cross cutting constructs: Requirements diagramg g


Principles Leading to Good Design

• Overall goals of good design:g g g• Increasing profit by reducing cost and increasing revenue• Ensuring that we actually conform with the requirements• Accelerating development• Accelerating development• Increasing qualities such as

− UsabilityEfficienc− Efficiency

− Reliability− Maintainability

R bilit− Reusability


Design Principle 1

• Divide and conquer• Trying to deal with something big all at once is

normally much harder than dealing with a series of smaller thingssmaller things− Separate people can work on each part.− An individual software engineer can specialize.

E h i di id l t i ll d th f i− Each individual component is smaller, and therefore easier to understand.

− Parts can be replaced or changed without having to l t i l h th treplace or extensively change other parts.


Design Principle 2

• Increase cohesion where possible:• A subsystem or module has high cohesion if it keeps

together things that are related to each other, and keeps out other thingskeeps out other things− This makes the system as a whole easier to understand

and changeType of cohesion:− Type of cohesion:− Functional, Layer, Communicational, Sequential, Procedural,

Temporal, Utility


Design Principle 3

• Reduce coupling where possible:g• Coupling occurs when there are interdependencies

between one module and another− When interdependencies exist changes in one place willWhen interdependencies exist, changes in one place will

require changes somewhere else.− A network of interdependencies makes it hard to see at a

glance how some component worksglance how some component works.− Type of coupling:− Content, Common, Control, Stamp, Data, Routine Call,

T I l i /I t E t lType use, Inclusion/Import, External


Design Principle 4

• Keep the level of abstraction as high as possibleg• Ensure that your designs allow you to hide or defer

consideration of details, thus reducing complexity− A good abstraction is said to provide information hidingA good abstraction is said to provide information hiding− Abstractions allow you to understand the essence of a

subsystem without having to know unnecessary details


Design Principle 5

• Increase reusability where possibley• Design the various aspects of your system so that they

can be used again in other contexts− Generalize your design as much as possibleGeneralize your design as much as possible− Follow the preceding three design principles− Design your system to contain hooks− Simplify your design as much as possible


Design Principle 6

• Reuse existing designs and code where possibleg g• Design with reuse is complementary to design for

reusability− Actively reusing designs or code allows you to takeActively reusing designs or code allows you to take

advantage of the investment you or others have made in reusable components

Cloning should not be seen as a form of reuse− Cloning should not be seen as a form of reuse


Design Principle 7

• Design for flexibilityg y• Actively anticipate changes that a design may have to

undergo in the future, and prepare for them− Reduce coupling and increase cohesionReduce coupling and increase cohesion− Create abstractions− Do not hard-code anything− Leave all options open− Do not restrict the options of people who have to modify

the system later − Use reusable code and make code reusable


Design Principle 8

• Anticipate obsolescence• Plan for changes in the technology or environment so

the software will continue to run or can be easily changed− Avoid using early releases of technology− Avoid using software libraries that are specific to particular

environments− Avoid using undocumented features or little-used features

of software libraries− Avoid using software or special hardware from companies

that are less likely to provide long term supportthat are less likely to provide long-term support− Use standard languages and technologies that are

supported by multiple vendors


Design Principle 9

• Design for Portabilityg y• Have the software run on as many platforms as

possible− Avoid the use of facilities that are specific to one particularAvoid the use of facilities that are specific to one particular

environment− E.g. a library only available in Microsoft Windows


Design Principle 10

• Design for testabilityg y• Take steps to make testing easier− Design a program to automatically test the software

Ensure that all the functionality of the code can by− Ensure that all the functionality of the code can by driven by an external program, bypassing a graphical user interface

In Java you can create a main() method in each class in− In Java, you can create a main() method in each class in order to exercise the other methods


Design Principle 11

• Design defensivelyg y• Never trust how others will try to use a component you

are designing− Handle all cases where other code might attempt to useHandle all cases where other code might attempt to use

your component inappropriately− Check that all of the inputs to your component are valid:

the preconditionsthe preconditions− Unfortunately, over-zealous defensive design can result

in unnecessarily repetitive checking


Design by contract

• A technique that allows you to design defensively in y g yan efficient and systematic way• Key idea

− each method has an explicit contract with its callerseach method has an explicit contract with its callers• The contract has a set of assertions that state:

− What preconditions the called method requires to be true when it starts executingstarts executing

− What postconditions the called method agrees to ensure are true when it finishes executing

− What invariants the called method agrees will not change as it g gexecutes


Techniques for making design decisions

• Using priorities and objectives to decide among alternatives

1. List and describe the alternatives for the design decision.2. List the advantages and disadvantages of each alternative

with respect to your objectives and priorities.3. Determine whether any of the alternatives prevents you

from meeting one or more of the objectives.4 Ch th lt ti th t h l t b t t4. Choose the alternative that helps you to best meet your

objectives. 5. Adjust priorities for subsequent decision making.


Writing a Good Design Document

• Design documents as an aid to making better g gdesigns• They force you to be explicit and consider the important

issues before starting implementation.issues before starting implementation. • They allow a group of people to review the design and

therefore to improve it.• Design documents as a means of communication• Design documents as a means of communication.

− To those who will be implementing the design.− To those who will need, in the future, to modify the design.− To those who need to create systems or subsystems that− To those who need to create systems or subsystems that

interface with the system being designed.


When writing the document

• Avoid documenting information that would be readily obvious to a skilled programmer or designer.

• Avoid writing details in a design document that would be better placed as comments in the code.be better placed as comments in the code.

• Avoid writing details that can be extracted automatically from the code, such as the list of public methodsmethods.


Software Architecture

• Software architecture is process of designing the g gglobal organization of a software system, including:• Dividing software into subsystems.

Deciding how these will interact• Deciding how these will interact.• Determining their interfaces.− The architecture is the core of the design, so all software

engineers need to understand it.− The architecture will often constrain the overall efficiency,

reusability and maintainability of the system.


Definition of Software Architecture

• Definition: The software architecture of a program or computing system is the structure or structures of the system, which compromise software elements, the externally visible properties of those elements, and relationships among them.

• Quality criteria of software architectures:• Availability• Modifiability• Performance• Security• Security• Testability• Usability


The importance of software architecture

• Why you need to develop an architectural model:y y• To enable everyone to better understand the system• To allow people to work on individual pieces of the

system in isolationsystem in isolation• To prepare for extension of the system• To facilitate reuse and reusability


Contents of a good architectural model

• A system’s architecture will often be expressed in yterms of several different views• The logical breakdown into subsystems

The interfaces among the subsystems• The interfaces among the subsystems • The dynamics of the interaction among components at

run time• The data that will be shared among the subsystems• The components that will exist at run time, and the

machines or devices on which they will be locatedmachines or devices on which they will be located


Design stable architecture

• To ensure the maintainability and reliability of a y ysystem, an architectural model must be designed to be stable. • Being stable means that the new features can be easily• Being stable means that the new features can be easily

added with only small changes to the architecture


Developing an architectural model

• Start by sketching an outline of the architecturey g• Based on the principal requirements and use cases• Determine the main components that will be needed

Ch th i hit t l tt• Choose among the various architectural patterns− Multi-Layer− Client-serverC e t se e− Pipe-and-filter

• Suggestion: have several different teams independently d l fi t d ft f th hit t ddevelop a first draft of the architecture and merge together the best ideas


Developing an architectural model

• Refine the architecture− Identify the main ways in which the components will

interact and the interfaces between them− Decide how each piece of data and functionality will beDecide how each piece of data and functionality will be

distributed among the various components− Determine if you can re-use an existing framework, or if

you can build a frameworkyou can build a framework• Consider each use case and adjust the architecture

to make it realizable• Mature the architecture


Constraints

• On the technical system architecture:y• Standards and design patterns• Interdependencies among various systems and components• Results of feasibility studies• Results of feasibility studies• Production and service requirements• Modifiability and testability requirements• Expenditure and risk estimates


Constraints and conflicts of objectives

• Reuse, or building block use, of technical gcomponents in various vehicle series• Multiple use of engines/transmissions in different series

influences architecture of electronics, but one ECU is usedinfluences architecture of electronics, but one ECU is used with different software version

• Different vehicle variants within a vehicle seriesO ti l t t d d i t• Optional extras vs standard equipment

• Country specific equipment variants• Component-oriented reuse• Component-oriented reuse


Specification of Software Architecture

• Based on Analysis of Software Requirementsy• Specification of software components and interfaces

− Data interfaces− Control interfacesControl interfaces− Onboard interfaces− Offboard interfaces

• Specification of software layersSpecification of software layers− AUTOSAR

• Specification of operating statesnormal operation− normal operation

− parameterization− updating


AUTOSAR

• AUTomotive Open System ARchitecture is an open yand standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers and tool developerssuppliers and tool developers

• Objective is to create and establish open standardsfor automotive Electrics/Electronics architecturesthat will provide a basic infrastructure to assist withdeveloping vehicular software, user interfaces and management for all application domainsmanagement for all application domains

• A platform for future vehicle applications


AUTOSAR

• paves the way for innovative electronic systems thaty yfurther improve performance, safety and environmental friendliness

• is a key enabling technology to manage the growing• is a key enabling technology to manage the growingelectrics/electronics complexity

• aims to be prepared for the upcoming technologiesp p p g gand to improve cost-efficiency without making anycompromise with respect to qualityfacilitates the exchange and update of software and• facilitates the exchange and update of software and hardware over the service life of the vehicle


AUTOSAR

• Who?• OEMs− DaimlerChrysler, Volkwagen, PSA, Toyota, Ford,

Opel Fiat Honda Mazda Renault Nissan etcOpel, Fiat, Honda, Mazda, Renault, Nissan, etc.• suppliers− generic Tier 1 supplier: Bosch, Continental,

SiemensVDO, Alpine, etc.− standard software, tools and services− semi-conductors− semi-conductors


AUTOSAR

• Why AUTOSAR?y• Increasing complexity of software in automotive systems• No standardized software architecture

• Main motivations• Management of E/E complexity associated with growth in

functional scope• Flexibility for product modification, upgrade and update• Scalability of solutions within and across product linesy p• Improved quality and reliability of E/E systems


AUTOSAR

• Main goalsg• Fulfillment of future vehicle requirements, such as,

availability and safety, SW upgrades/updates and maintainability

• Increased scalability and flexibility to integrate and transfer functions

• Higher penetration of "Commercial off the Shelf" SW and HWHigher penetration of Commercial off the Shelf SW and HW components across product lines

• Improved containment of product and process complexity and riska d s

• Cost optimization of scalable systems


AUTOSAR

• AUTOSAR software components• Fundamental design concept is separation between

infrastructure and application• Application consists of interconnected software componentsApplication consists of interconnected software components• Atomic software component: a software component can not

be distributed over several ECUs• AUTOSAR software component implementation is• AUTOSAR software component implementation is

independent from the infrastructure


AUTOSAR

• Communication patternsClient – Server

• Server: provider of serviceCli t f i• Client: user of service

• Client initiates communication

• Single component can be server and client

• Synchronous and asynchronous communication is possible


AUTOSAR

• Communication patternsSender - Receiver

• Asynchronous distribution of informationof information

• No response from receivers• Sender does not know the

b id tit f thnumber or identity of the receivers


AUTOSAR

• Layered Software Architecturey


uml â€“ unified modeling language

Documents