UML - Beispiele

UML - Beispiele

Software Modeling, UML 01.03.20 Brno Dr.J. Withalm Program and System Engineering PSE Overview Motivation/Introduction CMMI-a brief overview UML-a brief overview Hints &Tips Which UML models are most appropriate to be applied in which KPAs 01.03.20 Brno Dr. J. Withalm 2

Program and System Engineering PSE Definitions/1 Quality: the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs (ISO8402). Software quality: the totality of features and characteristics of a software product or service that bear on its ability to satisfy stated or implied needs (ISO/IEC9126 ) Quality means to fulfill requirements 01.03.20 Brno Dr. J. Withalm 3 Program and

System Engineering PSE Software Product Quality ISO 8402 Quality Vocabulary: The totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs. What does needs means? 01.03.20 Brno Dr. J. Withalm 4 Program and System Engineering PSE NEEDS Needs is expectations for the effects of a product. A user wants not a product itself but the effects of the product, which are needs.

It is difficult that real needs be identified either by a user or a planner. 01.03.20 Brno Dr. J. Withalm 5 Program and System Engineering PSE Needs and Requirements Identified needs must be transformed into requirements. However, a product that satisfies requirements does not always satisfies needs. 01.03.20 Brno Dr. J. Withalm

6 Program and System Engineering PSE QUALITY IN USE CONCEPTS Quality In Use (QIU) QIU is an aspect of a product quality. QIU is measured by the effects of the product when it is used. JTC1/SC7/WG6 introduced QIU concept in the ISO/ IEC 9126: Software Product Quality series. 01.03.20 Brno Dr. J. Withalm 7 Program and System Engineering PSE

QUALITY IN USE CONCEPTS States System Model Needs QIU Current Current States States Goal Goal States States Realized Realized States States Current Current System

System Proposed Proposed System System Developed Developed System System Effects Cause 01.03.20 Brno Dr. J. Withalm 8 Program and System Engineering PSE

QIU Definition and Characteristics ISO/IEC 9126-1 The capability of a software product to enable specified users to achieve specified goals with effectiveness, productivity, safety, and satisfaction in specified context of use. 01.03.20 Brno Dr. J. Withalm 9 Program and System Engineering PSE Requirements/1 Business oriented requirements Functional requirements Non functional requirements

01.03.20 Brno Dr. J. Withalm 10 Program and System Engineering PSE 01.03.20 Requirements/2 How to measure the fulfillment Brno Dr. J. Withalm 11 Program and System Engineering PSE

01.03.20 Requirements/3 How to establish Business Strategies Brno Dr. J. Withalm 12 Requirements/4 How to establish Business Models Program and System Engineering PSE P1 Product P4 Financial Aspects Vision &

Strategy Product Value proposition Customer Interface Target Customer Distribution Channel Relationship P2 Customer Interface Infrastructure Value Configuration Capability Partnership P3 Infrastructur

e Management 01.03.20 Brno Financial Aspects Cost Structure Revenue (Sharing) Model Dr. J. Withalm 13 Program and System Engineering PSE Requirements/5 Assessment Tree F V= 0,8218

p= 100 F1 F2 V 1= 0,847 V2= 0,805 p 1 = 40 F 11 p 2= 60 F 12 F 21 V11= 0,83 p 11= 90 v J= V12= 1 p 12= 10 F 23

V21= 0,9 p 21= 50 V22= 0,75 p 22= 10 V23= 0,7 p 23= 40 (p, x V,) j 100 F 211 F 212 V211= 1 v 21= F 22 30 x 1 + 10 x 0 + 60 x 1 = 0,9 100

01.03.20 Brno p 211= 30 F 213 V212= 0 p 212= 10 V213= 1 p 213= 60 Dr. J. Withalm 14 Program and System Engineering PSE Requirements/6 Non Functional Requirements/Quality Characteristics

01.03.20 Brno reliability functional performance user friendliness time behaviour consume behaviour maintainability portability Dr. J. Withalm 15 Program and System Engineering PSE

01.03.20 Requirements/6 Action in SEM phases concerning quality evaluation SEM Phases Application of SEM Quality Evaluation Initiation Study Definition of quality objectives System Design Detailed Design Implementation Integration Direction for technical and quality assurance activities System Test

Acceptance Examination if quality objectives are reached Brno Dr. J. Withalm 16 Program and System Engineering PSE Requirements/7 SEM Software Quality Evaluation Definition Quality characteristics Subcharacteristics List of criteria / checklists Evaluation procedures 01.03.20 Brno

Dr. J. Withalm 17 Program and System Engineering PSE Requirements/10 Evaluation Procedures back up measuring point scaling system evaluation tree (functional performance) project specific procedures 01.03.20 Brno Dr. J. Withalm 20

Program and System Engineering PSE Requirements/10 Structuring of quality costs Quality related costs Error prevention cost Error costs Internal/external Test costs Cost to be conform to requirements Costs to be non conform to requirements Process related costs 01.03.20 Brno

Dr. J. Withalm 21 Program and System Engineering PSE Requirements/11 Why SW projects are stranding? 95% stranded because Customer and Developer have different views about requirements Implicit requirements Different knowledge of domain No technical knowledge of customers Concerning the non functional requirements!!! Change requests Market driven Business oriented requirements No clear understanding of impact of requirements 01.03.20

Brno Dr. J. Withalm 22 Program and System Engineering PSE Requirements/12 Whats the promising of OO Improvement of requirement engineering by Closing/narrowing the semantic gap In structured analysis/design mapping between the phases were the main obstacles Improvement of maintainability Enabling of requirement tracing through all phases. Improvement of Quality by reusing components Improvement of the portability 3 - 30 01.03.20

Brno Dr. J. Withalm 23 Program and System Engineering PSE Requirements/13 And what happened Improvement of requirement engineering was substantially and accomplished mainly by applying: OMT and then UML Maintainability and Requirement Tracing were improved as consequence of applying UML With regard to reusing of components and portability no clear trends are recognized. 01.03.20 Brno

Dr. J. Withalm 24 Program and System Engineering PSE Overview Motivation/Introduction CMMI-a brief overview UML-a brief overview Hints &Tips Which UML models are most appropriate to be applied in which KPAs 01.03.20 Brno Dr. J. Withalm 25 Program and System Engineering PSE

CMMI - Capability Maturity Model Integration model for evaluating software/hardware/systems engineering organizations developed by the Software Engineering Institute (SEI) reference model also for derived methods such as Bootstrap and Siemens Process Assessments (CT SE3) 01.03.20 Brno Dr. J. Withalm 26 Program and System Engineering PSE CMMI Maturity Levels (staged) Benefit Benefit

Quality Each transition takes 1-3 years ! predictable process consistent process 2 Managed disciplined process 1 Initial Risk 01.03.20 Brno continuously improving process

5 Optimizing 4 Quantitatively Managed process control quantitative process management 3 Defined process definition basic project management and control Dr. J. Withalm 27 Program and

System Engineering PSE Characteristics of an immature process The process is ad hoc and generally based on improvisation (by developers and managers). Procedures, if existing at all, are not being adhered to. Strong dependency on individuals (heroes). Product quality and performance very difficult to predict. Product quality and functionality downgrading to meet deadlines, but deadlines are still exceeded. The use of new technologies involves major risks. During a crisis, guidelines/rules are often abandoned as unnecessarily complicating. 01.03.20 Brno Dr. J. Withalm 28 Program and System Engineering PSE

Characteristics of a mature process Standardized process, defined and documented has been understood and accepted is being applied is alive Visible support through management Clear definition and understanding of roles and responsibilities Well-established control process compliance is being monitored and enforced Consistent with the staffs current way of working Measurable and being measured Supported by means of suitable technologies and tools 01.03.20 Brno Dr. J. Withalm 29 Program and System Engineering PSE Organizational Innovation and Deployment

CMMI Process AreasCausal Analysis & Resolution Optimizing (5) Quantitative Process Management Quantitatively Software Quality Management Managed (4) Requirement Development Technical Solution Product Integration Verification Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management Risk Management Decision Analysis and Resolution 01.03.20 Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Brno Configuration Management

Defined (3) Managed (2) Dr. J. Withalm 30 Program and System Engineering PSE Process Areas and Specific Goals of ML 2 (1) Requirements Management Project Planning Project Monitoring and Control 01.03.20 Brno Manage the requirements of the projects products and product components and identify inconsistencies between those requirements and the project plans and work

products. Manage Requirements. Establish and maintain plans that define project activities. Establish Estimates Develop a Project Plan Obtain Commitment to the Plan Provide understanding of the projects progress so that appropriate corrective actions can be taken when the projects performance deviates significantly from the plan Monitor Project against plan Manage corrective actions to closure Dr. J. Withalm 31 Program and System Engineering PSE Process Areas and Specific Goals of ML 2 (3) Configuration Management

Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting and configuration audits. Establish baselines Track and control changes Establish integrity 01.03.20 Brno Dr. J. Withalm 32 Program and System Engineering PSE Process Areas and Specific Goals of ML 3 (1) Requirement Development

Technical Solution Produce and analyze customer, product and product component requirements. Develop customer requirements Develop product requirements Analyze and validate requirements Design, develop and implement solutions to requirements. Solutions, designs and implementations encompass either singly or in combinations as appropriate. Select product component solutions Develop the design Implement product design 01.03.20 Brno Dr. J. Withalm 33 Program and System Engineering PSE

Process Areas and Specific Goals of ML 3 (2) Product Integration Assemble the product from the product components, ensure that the product - as integrated works properly (whole functionality) and deliver the product. Prepare for product integration Ensure interface compatibility Assemble product components and deliver the product Verification 01.03.20 Brno Ensure that the selected work products meet their specified requirements. Prepare for verification Perform peer reviews Verify selected work products Dr. J. Withalm

34 Program and System Engineering PSE Process Areas and Specific Goals of ML 3 (3) Validation Demonstrate that the product or product components fulfills its intended use when placed in its intended environment Prepare for validation Validate product or product components (must be suitable for use in their intended operating environment) Organizational Process Focus 01.03.20 Brno Plan and implement organizational process

improvement based on a thorough understanding of the current strengths and weaknesses of the organizations processes and process assets. Determine process improvement opportunities Plan and implement process improvement activities Dr. J. Withalm 35 Assessments/ Certification history in general Program and System Engineering PSE - after 2 nd world war QA was set up by Deming & Juran in Japan in USA, Europe still classical quality validation by HW development QA did not get acceptance till present times so-called QA in software in the beginning was only restricted to tests and error count in USA above all military (DoD) starts with QA, which is also checked

with audits (AQAP) Siemens starts in 1980 with QA system (CSA) to get through audits quality validation sample audits on the finished product 01.03.20 Brno back up quality assurance current checks during the development process Dr. J. Withalm 36 Program and System Engineering PSE 01.03.20

Assessments/ Certification history in general/2 back up - begin of 1980 quality label for SW (pure quality validation) - discussion about certification since the middle eighties - in Germany "Made in Germany" syndrom delays certification - cooperation since 1990 with standards institute on ISO 9000 ff - since 1992 pressure upon Siemens regarding certification Brno

Dr. J. Withalm 37 Assessments/ Certification history in general /3 connection SW-engineering - QA Program and System Engineering PSE 01.03.20 - SW engineering has 3 dimensions: organization - method - technology - organization means: - application of a method (e.g. SEM, SEPP,....) - verification of this application - organization of QA - record of primary data (metrics)

- method means e.g.: - functional development method - object oriented development method - technology means: - with which tools the method is set up you will find this synonym also on informatic institutes or universities - in the beginning SW-engineers were only interested in technology Brno Dr. J. Withalm 38 Program and System Engineering PSE Overview Motivation/Introduction

CMMI-a brief overview UML-a brief overview Hints &Tips Which UML models are most appropriate to be applied in which KPAs 01.03.20 Brno Dr. J. Withalm 39 Program and System Engineering PSE Building blocks of the UML The vocabulary of the UML encompasses three kinds of building blocks: Things are the abstractions that are first class citizens in a model relationships tie these things together diagrams group interesting collections of things 01.03.20

Brno Dr. J. Withalm 44 Program and System Engineering PSE Things in the UML There are four kinds of things in the UML structural things behavioral things grouping things annotational things these things are the basic object-oriented building blocks of the UML you use them to write well-formed models 01.03.20 Brno Dr. J. Withalm

45 Program and System Engineering PSE Structural things 1 Are the nouns of UML models these are the mostly static parts of a model, representing elements that are either conceptual or physical in all, there are seven kinds of structural things 01.03.20 Brno 2001-10-01 Dr. J. Withalm 46 Program and System Engineering PSE

Structural things 2 classes/1 A class is a description of a set of objects that share the same attributes operations relationships semantics a class implements one or more interfaces 01.03.20 Brno Dr. J. Withalm 47 Program and System Engineering PSE Structural things/3 classes/2 Graphically, a class is rendered as a rectangle, usually including its name

attributes operations Window origin size open() close() move() display() 01.03.20 Brno Dr. J. Withalm 48 Program and System Engineering PSE Structural things/4 interfaces/1 An interface is a collection of operations that specify a service of a class

component An interface therefore describes the externally visible behavior of that element an interface defines a set of operations specifications (that is, their signatures) but never a set of operations implementations 01.03.20 Brno Dr. J. Withalm 49 Program and System Engineering PSE Structural things/5 interfaces/2 Graphically, an interface is rendered as a circle together with its name An interface rarely stands alone Rather, it is typically attached to the class or component that realises the interface

ISpelling 01.03.20 Brno Dr. J. Withalm 50 Program and System Engineering PSE Structural things/6 collaboration/1 A collaboration defines an interaction is a society of roles and other elements that work together to provide some cooperative behavior thats bigger than the sum of all the elements collaborations have structural and behavioral dimensions A given class might participate in several collaborations these collaborations therefore represent the implementation of patterns that make

up a system 01.03.20 Brno Dr. J. Withalm 51 Program and System Engineering PSE Structural things/7 collaboration/2 Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name Chain of responsibility 01.03.20 Brno Dr. J. Withalm

52 Program and System Engineering PSE Structural things/8 use cases/1 A use case is a description of a set of sequence of actions that a system performs that yields an observable result of value to a particular actor A use case is used to structure behavioral things in a model a use case is realised by a collaboration 01.03.20 Brno Dr. J. Withalm 53 Program and

System Engineering PSE Structural things/9 use cases/2 Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name place order 01.03.20 Brno Dr. J. Withalm 54 Program and System Engineering PSE Structural things/10 The remaining three things active classes components

nodes Are all class-like, meaning they also describe a set of objects that share the same attributes, operations, relationships and semantics However, these three are different enough and are necessary for modeling certain aspects of an object-oriented system, and so they warrant special treatment 01.03.20 Brno Dr. J. Withalm 55 Program and System Engineering PSE Structural things/11 active class/1 An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity an active class is just like a class except

that its objects represent elements whose behavior is concurrent with other elements 01.03.20 Brno Dr. J. Withalm 56 Program and System Engineering PSE Structural things/12 active class/2 Graphically, an active class is rendered just like a class, but with heavy lines, usually including its name, attributes, and operations EventManager suspend() flush() 01.03.20

Brno Dr. J. Withalm 57 Program and System Engineering PSE Structural things/13 The remaining two elements-component, and nodes- are also different they represent physical things, whereas the previous five things represent conceptual or logical things 01.03.20 Brno Dr. J. Withalm 58 Program and System Engineering

PSE Structural things/14 component/1 A component is a physical and replaceable part of a system that conforms to and provides the realisation of a set of interfaces in a system, youll encounter different kinds of deployment components, such as COM+ Java Bean as well as components that are artifacts of the developing process, such as source code files a component typically represents the physical packaging of otherwise logical elements Classes, interfaces, and collaborations 01.03.20 Brno Dr. J. Withalm 59 Program and

System Engineering PSE Structural things /15 component/2 Graphically, a component is rendered as a rectangle with tabs, usually including only its name orderform.java 01.03.20 Brno Dr. J. Withalm 60 Program and System Engineering PSE Structural things/16 node/1 A node is a physical element that exists at run time and represents a computational

resource generally having at least some memory and, often, processing capability A set of components may reside on a node and may also migrate from node to node 01.03.20 Brno Dr. J. Withalm 61 Program and System Engineering PSE Structural things/17 node/2 Graphically, a node is rendered as a cube, usually including only its name Server 01.03.20

Brno Dr. J. Withalm 62 Program and System Engineering PSE Behavioral things 1 Behavioral things are dynamic parts of UML models these are the verbs of a model, representing behavior over time and space in all, there are two primary kinds of behavioral things 01.03.20 Brno Dr. J. Withalm 63 Program and

System Engineering PSE Behavioral things/2 interaction/1 An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose the behavior of a society of objects or of an individual operation may be specified with an interaction an interaction involves a number of other elements,including Messages Action sequences the behavior invoked by a message Links the connection between objects 01.03.20 Brno Dr. J. Withalm 64

Program and System Engineering PSE Behavioral things/3 interaction/1 Graphically, a message is rendered as a directed line, almost always including the name of its operation displa y 01.03.20 Brno Dr. J. Withalm 65 Program and System Engineering PSE Behavioral things/4

state machine/1 A state machine is a behavior that specifies the sequence of states an object or an interaction goes through during its lifetime in response to events, together with its responses to those events the behavior of an individual class or a collaboration of classes may be specified with a state machine a state machine involves a number of other elements, including States Transitions the flow from state to state Activities the response to a transition 01.03.20 Brno Dr. J. Withalm 66 Program and System Engineering PSE

Behavioral things/5 state machine/2 Graphically, a state is rendered as a rounded rectangle, usually including its name and its substates , if any Waiting 01.03.20 Brno Dr. J. Withalm 67 Program and System Engineering PSE Grouping things/1 Grouping things are the organisational parts of UML models these are the boxes into which a model can be decomposed in all, there is one primary kind of grouping

thing, namely, packages 01.03.20 Brno Dr. J. Withalm 68 Program and System Engineering PSE Grouping things/2 package/1 A package is a general-purpose mechanism for organising elements into groups structural things, behavioral things, and even other grouping things may be placed in a package unlike components (which exist at run time), a package is purely conceptual Meaning that it exists only at development time

01.03.20 Brno Dr. J. Withalm 69 Program and System Engineering PSE Grouping things/3 package/2 Graphically, a package is rendered as a tabbed folder Usually including only its name and, sometimes, its contents Business rules 01.03.20 Brno Dr. J. Withalm

70 Program and System Engineering PSE Annotational things/1 Annotational things are the explanatory parts of UML models these are the comments you may apply to describe illuminate remark There is one primary kind of annotational thing, called a note 01.03.20 Brno Dr. J. Withalm 71 Program and System Engineering PSE

Annotational things/2 note/1 A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements 01.03.20 Brno Dr. J. Withalm 72 Program and System Engineering PSE Annotational Things/3 note/2 Graphically, a note is rendered as a rectangle with a dog-eared corner, together with a textual or graphical comment return copy

of self 01.03.20 Brno Dr. J. Withalm 73 Program and System Engineering PSE Relationships in the UML There are four kinds of relationships in the UML dependency association generalisation realisation these relationships are the basic relational building blocks of the UML you use them to write well-formed models 01.03.20

Brno Dr. J. Withalm 74 Program and System Engineering PSE Dependency/1 A dependency is a semantic relationship between two things in which a change to one (the independent thing) may affect the semantics of the other thing (the dependent thing) 01.03.20 Brno Dr. J. Withalm 75 Program and

System Engineering PSE Dependency/2 Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally including a label 01.03.20 Brno Dr. J. Withalm 76 Program and System Engineering PSE Association/1 An association is a structural relationship that describes a set of links A link being a connection among objects Aggregation is a special kind of association representing a structural relationship

between a whole and its parts 01.03.20 Brno Dr. J. Withalm 77 Program and System Engineering PSE Association/2 Graphically, an association is rendered as a solid line, possible directed, occasionally including a label, and often containing other adornments Such as multiplicity and role names 0..1 employer 01.03.20 Brno

* employee Dr. J. Withalm 78 Program and System Engineering PSE generalisation/1 A generalisation is a specialisation/ generalisation relationship in which objects of the specialised element (the child) are substitutable for objects of the generalised element (the parent) in this way, the child shares the structure and the behavior of the parent 01.03.20 Brno Dr. J. Withalm

79 Program and System Engineering PSE Generalisation/2 Graphically, a generalisation relationship is rendered as a solid line with a hollow arrowhead pointing to the parent 01.03.20 Brno Dr. J. Withalm 80 Program and System Engineering PSE Realisation/1 A realisation is a semantic relationship between classifiers wherein one classifier specifies a

contract that another classifier guarantees to carry out youll encounter realisation relationship in two places between interfaces and the classes or components that realise them between use cases and the collaborations that realise them 01.03.20 Brno Dr. J. Withalm 81 Program and System Engineering PSE Realisation/2 Graphically, a realisation relationship is rendered as a cross between a generalisation and a dependency relationship

01.03.20 Brno Dr. J. Withalm 82 Program and System Engineering PSE Diagrams in the UML/3 The UML includes nine such diagrams class diagram object diagram use case diagram sequence diagram collaboration diagram statechart diagram activity diagram component diagram deployment diagram 01.03.20 Brno

Dr. J. Withalm 85 Program and System Engineering PSE Diagrams in the UML/4 class diagram A class diagram shows a set of classes interfaces collaborations these diagrams are the most common diagrams found in modeling objectoriented systems class diagrams address the static design view of a system class diagrams that include active classes address the static process view of a system 01.03.20 Brno Dr. J. Withalm

86 Program and System Engineering PSE Diagrams in the UML/5 object diagram An object diagram shows a set of objects and their relationships object diagrams represent static snapshots of instances of the things found in class diagrams these diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases 01.03.20 Brno Dr. J. Withalm 87

Program and System Engineering PSE Diagrams in the UML/6 use case diagram A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships use case diagrams address the static use case view of a system these diagrams are especially important in organising and modeling the behavior of a system 01.03.20 Brno Dr. J. Withalm 88 Program and System Engineering PSE

Diagrams in the UML/7 interaction diagram, sequence diagram An interaction diagram shows an interaction consisting of a set of objects and their relationships, including the message that may be dispatched among them interaction diagrams address the dynamic view of a system 01.03.20 Brno Dr. J. Withalm 89 Program and System Engineering PSE Diagrams in the UML/8 interaction diagram, sequence diagram A sequence diagram is an interaction diagram that emphasises the timeordering of messages

01.03.20 Brno Dr. J. Withalm 90 Program and System Engineering PSE Diagrams in the UML/9 interaction diagram, collaboration diagram A collaboration diagram is an interaction diagram that emphasises the structural organisation of the objects that send and receive messages sequence diagrams and collaboration diagrams are isomorphic Meaning that you can take one and transform it into the other 01.03.20 Brno

Dr. J. Withalm 91 Program and System Engineering PSE Diagrams in the UML/10 statechart diagrams A statechart diagram shows a state machine consisting of states, transitions, events, and activities statechart diagrams address the dynamic view of a system they are especially important in modeling the behavior of an object, which is especially useful in modeling reactive systems 01.03.20 Brno Dr. J. Withalm

92 Program and System Engineering PSE Diagrams in the UML/11 activity diagram An activity diagram is a special kind of a statechart diagram that shows the flow from activities within a system activity diagrams address the dynamic view of a system they are especially important in modeling the function of a system and emphasize the flow of control among objects. 01.03.20 Brno Dr. J. Withalm 93

Program and System Engineering PSE Diagrams in the UML/12 component diagram A component diagram shows the organisation and dependencies among a set of components component diagrams address the static implementation view of a system they are related to class diagrams in that a component typically maps to one or more classes, interfaces, or collaborations 01.03.20 Brno Dr. J. Withalm 94 Program and System Engineering PSE

Diagrams in the UML/13 deployment diagram A deployment diagram shows the configuration of run-time processing nodes and the components that live on them deployment diagrams address the static deployment view of an architecture they are related to component diagrams in that a node typically encloses one or more components 01.03.20 Brno Dr. J. Withalm 95 Program and System Engineering PSE Architecture/5 vocabulary functionali ty

behavior Design view system assembly configuration management Implementation view Use case view Process view performance scalability throughput 01.03.20 Brno Deployment view system topology distribution delivery installation Dr. J. Withalm 116

Program and System Engineering PSE Architecture/6 use case view The use case view of a system encompasses the use case that describe the behavior of the system as seen by its end users, analysts, and testers this view doesnt really specify the organisation of a software system rather, it exists to specify the forces that shape the systems architecture with the UML the static aspect of this view are captured in the use case diagram the dynamic aspects of this view are captured in interaction diagrams statechart diagrams activity diagrams 01.03.20 Brno Dr. J. Withalm

117 Program and System Engineering PSE Architecture/7 design view The design view of a system encompasses the class, interfaces, and collaborations that form the vocabulary of the problem and its solution this view primarily supports the functional requirements of the system meaning the services that the system should provide to its end users with the UML the static aspect of this view are captured in class diagrams and object diagrams the dynamic aspect of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams 01.03.20

Brno Dr. J. Withalm 118 Program and System Engineering PSE Architecture/8 process view The process view of a system encompasses the threads and processes that form the systems concurrency and synchronisation mechanisms this view primarily addresses the performance, scalability, and throughput of the system with the UML the static and dynamic aspects of this view are captured in the same kinds of diagrams as for the design view, but with a focus on the active classes that represent these threads and processes 01.03.20

Brno Dr. J. Withalm 119 Program and System Engineering PSE Architecture/9 implementation view The implementation view of a system encompasses the components and files that are used to assemble and release the physical system this view primarily addresses the configuration management of the systems releases made up of somewhat independent components and files that can be assembled in various ways to produce a running system with the UML the static aspects of this view are captured in component diagrams the dynamic aspects of this view are captured in interaction diagrams,

statechart diagrams, and activity diagrams 01.03.20 Brno Dr. J. Withalm 120 Program and System Engineering PSE Architecture/10 deployment view The deployment view of a system encompasses the nodes that form the systems hardware topology on which the system executes this view primarily addresses the distribution, delivery, and installation of the parts that make up the physical system with the UML the static aspects of this view are captured in deployment diagrams the dynamic aspects of this view are captured in

interaction diagrams, statechart diagrams, and activity diagrams 01.03.20 Brno Dr. J. Withalm 121 Program and System Engineering PSE Software development life cycle/2 use case driven Use case driven means that use cases are used as a primary artifact for establishing the desired behavior of the system for verifying and validating the systems architecture for testing, and for communicating among the stakeholders of the project 01.03.20

Brno Dr. J. Withalm 125 Program and System Engineering PSE Software development life cycle/3 architecture-centric Architecture-centric means that a systems architecture is used as a primary artifact for conceptualising constructing managing and evolving the system under development 01.03.20 Brno Dr. J. Withalm

126 Program and System Engineering PSE Software development life cycle/4 iterative and incremental An iterative process is one that involves managing a stream of executable releases an incremental process is one that involves the continuous integration of the systems architecture to produce these releases, with each new release embodying incremental improvements over the other together, an iterative and incremental process is risk-driven meaning that each new release is focused on attacking and reducing the most significant risks to the success of the project 01.03.20 Brno

Dr. J. Withalm 127 Program and System Engineering PSE Overview Motivation/Introduction CMMI-a brief overview UML-a brief overview Hints &Tips Which UML models are most appropriate to be applied in which KPAs 01.03.20 Brno Dr. J. Withalm 135 Which UML Model will support Program and System Engineering

Key Process Area of CMMI PSE UML-Models REQM CM us in which RD TS PI VER VAL Use cases deployment State chart Interfaces Process and threads

Events and signals components interactions collaborations 01.03.20 Brno Dr. J. Withalm 136 Program and System Engineering PSE REQM (Requirement Management) Specific goal 1: Manage Requirements Obtain an understanding of requirements Obtain commitment to requirements Manage requirement changes Maintain bidirectional traceability of requirements Identify inconsistencies between project

work and requirements 01.03.20 Brno Dr. J. Withalm 137 Program and System Engineering PSE REQM /2 01.03.20 Brno Use cases, state machine, activity diagram, statechart diagram, interactive diagram try to establish use cases for each requirement each use case should be analyzed by

interaction diagram which should show the messaging between the objects Use cases give you a first impression about classes/objects Try to find out which objects could be active objects in that way that they react to events and which are not active objects For each object try to find out in which states they are and when transitions take place Try to find out what activities take place in objects Try to get commitments for all these questions from project participants. Dr. J. Withalm 138 Program and System Engineering PSE CM (Configuration Management) Specific goal 1: establish baseline Identify configuration items Establish a CM system Create a release baseline

Specific goal 2: track and control changes Track change requests Control configuration items Specific goal 3: Establish integrity Establish configuration management records Perform configuration audits . 01.03.20 Brno Dr. J. Withalm 139 Program and System Engineering PSE RD (Requirements Development) Specific goal 1: develop customer needs Elicit needs Develop the customer requirement Specific goal 2:develop product requirements Establish product and product-component

requirements Allocate product-component requirements Identify interface requirements Specific goal 3: analyze and validate requirements establish operational concepts and scenarios Establish a definition of required functionality Catalogue requirements Analyze requirements to achieve balance Validate requirements with comprehensive methods. 01.03.20 Brno Dr. J. Withalm 140 Program and System Engineering PSE RD/2 (Transform stakeholder needs, expectation, constrains and interfaces with customer required /Establish and maintain product and product component requirements, which are basics on the customers requirements/ Allocate the requirements for each

product component) 1. 2. 3. 4. 01.03.20 Brno It could be very interesting if all stakeholders see the same use cases in that case it is not necessary to undertake further modeling as state machines, interactive diagrams Start with the established use case diagrams of the customer requirements Derive a collaboration diagram Establish a component diagram Establish a deployment diagram Thanks to reverse engineering methodologies we have the chance from component diagrams evaluating classes,

interfaces, collaborations reversing of collaborations brings us use cases Dr. J. Withalm 141 Program and System Engineering PSE RD/3 (Identify interface requirements ) Use cases are the door between the system and the outer world Collaborations have realization relationships to use cases Each collaboration contains classes, interfaces, active classes Each class has attributes and in that way an interface establish and maintain operational concepts and association scenarios Basics are use case diagrams Furthermore we need component/deployment diagrams

01.03.20 Brno Dr. J. Withalm 142 RD/4 (Establish a definition Program and System Engineeringrequired functionality) PSE of Basics are use cases Next step collaboration diagrams interaction diagrams statechart diagrams activity diagrams Analyze requirements to ensure that they are necessary and sufficient Use case diagrams Analyze requirements to balance stakeholder needs and constraints Use case diagram Validate requirements to ensure the resulting product will perform as

indented in the users environment using multiple techniques as appropriate 01.03.20 Brno Dr. J. Withalm 143 Program and System Engineering PSE TS (Technical Solutions) Specific goal 1: select product-component solutions Develop detailed alternative solutions and selection criteria Evolve operational concepts and scenarios Select product-component solutions Specific goal 2:develop the design Design the product or product component Establish a technical data package Design interfaces using criteria Perform make, buy, or reuse analyses

Specific goal 3: implement the product design Implement the design Develop product support documentation. 01.03.20 Brno Dr. J. Withalm 144 TS/2 ( develop detailed alternative solution and selection criteria/ Program and Evolve the operational concepts and scenarios/ Select the productSystem Engineering component solution that best satisfy the criteria established/ design PSE the product or product component ) Via use case establish different collaboration interaction, activity diagrams Its also useful to establish different component and deployment diagrams In case of concurrency different active classes From uses cases to component/deployment diagrams Component diagrams

Use cases, collaboration, component diagrams 01.03.20 Brno Dr. J. Withalm 145 Program and System Engineering PSE PI (Product Integration) Specific goal 1: prepare for product integration Determine integration sequence Establish the product integration environment Establish product integration procedures and criteria Specific goal 2: ensure interface compatibility Review interface descriptions for completeness Manage interfaces Specific goal 3: assemble product components and deliver the product Confirm readiness of product components for integration

Assemble product components Evaluate assembled product components Package and deliver the product or product component. 01.03.20 Brno Dr. J. Withalm 146 Program and System Engineering PSE 01.03.20 Validation and Verification Brno Dr. J. Withalm 147

Program and System Engineering PSE VER (Verification) Specific goal 1: prepare for verification Select work products for verification Establish the verification environment Establish verification procedures and criteria Specific goal 2: perform peer reviews Prepare for peer reviews Conduct peer reviews Analyze peer review data Specific goal 3: verify selected work products Perform verification Analyze verification results and identify corrective action 01.03.20 Brno Dr. J. Withalm 148

Program and System Engineering PSE VAL (Validation) Specific goal 1: prepare for validation Select work products for validation Establish the validation environment Establish validation procedures and criteria Specific goal 2: validate product or product components Perform validation Analyze validation results 01.03.20 Brno Dr. J. Withalm 149 Thank you for your attention! 01.03.20

Brno Dr.J. Withalm

Recently Viewed Presentations

  • Pocket Milling Machine - Fab Central

    Pocket Milling Machine - Fab Central

    Pocket Milling Machine Ultra-high speed micro milling machine Motivation A means to build micro structures using conventional machining techniques Portable machine tool Applications - milling microfluidic circuits ranging from 50 microns and above with varied channel geometries in a varity...
  • Gods Eternal Purpose, Eph. 3:11 Book of Nature

    Gods Eternal Purpose, Eph. 3:11 Book of Nature

    Mk. 16:15-16: And He said to them, "Go into all the world and preach the gospel to every creature. 16 He who believes and is baptized will be saved; but he who does not believe will be condemned." ... Lest...
  • FLUIDOS - WordPress.com

    FLUIDOS - WordPress.com

    Es igual en todas las direcciones y actúa mediante fuerzas perpendiculares a las paredes que lo contienen. El principio de Pascal fundamenta el funcionamiento de las genéricamente llamadas máquinas hidráulicas: la prensa, el gato, el freno, el ascensor y la...
  • CSI/CCE Computer Architecture

    CSI/CCE Computer Architecture

    Simple ALU Design How about the Control? The Control Unit A simple device Input and Output Operation of Machine Building the controller Finite State Remember how many coins have been put in the machine and what inputs are acceptable Read-Only...
  • ACT Health Branding - Pocket PC Creations

    ACT Health Branding - Pocket PC Creations

    How - Phase One - PICS How - Phase One - Manual How - Phase Two - Electronic Hardware Symbol PPT 8800 $ 2,500 Software Pocket PC Creations- 5 user $ 500 Translation HIBCC UPN repository $3,500 How - Phase...
  • Igneous Rocks

    Igneous Rocks

    Magma: molten rock below the Earth's surface. Lava: is magma that flows out onto the Earth's surface. The type of igneous rock that forms depends on the . composition. of the . magma. Of all of the compounds present in...
  • Knowledge Organiser Dark tourism shops Money raised from

    Knowledge Organiser Dark tourism shops Money raised from

    Rio De Janeiro is a city located in Brazil in South America. The city is one of the places in the world which offers slum tourism. Slum tourism is a type of tourism that involves visiting impoverished areas. It can...
  • Critical Thinking Chapter 11 Inductive Reasoning Lecture Notes

    Critical Thinking Chapter 11 Inductive Reasoning Lecture Notes

    Introduction. Inductive Argument: an argument in which the premises are intended to provide support, but not conclusive evidence, for the conclusion.