Software Modeling, UML 3/18/2018 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 KPA‘s 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“ (ISO 8402). „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/IEC 9126 ) Quality means to fulfill requirements 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? 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. 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. 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. § JTC 1/SC 7/WG 6 introduced QIU concept in the ISO/IEC 9126: Software Product Quality series. Brno Dr. J. Withalm 7
Program and System Engineering PSE QUALITY IN USE CONCEPTS Effects States – System Model Needs QIU Current States Goal States Realized States Current System Proposed System Developed System Cause 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. Brno Dr. J. Withalm 9
Program and System Engineering PSE Requirements/1 § Business oriented requirements § Functional requirements § Non functional requirements Brno Dr. J. Withalm 10
Program and System Engineering PSE Requirements/2 How to measure the fulfillment Brno Dr. J. Withalm 11
Program and System Engineering PSE Requirements/3 How to establish Business Strategies Brno Dr. J. Withalm 12
Requirements/4 How to establish Business Models Program and System Engineering PSE Product Customer Interface P 1 Product Value proposition Target Customer Distribution Channel Relationship P 4 Financial Aspects Vision & Strategy P 2 Customer Interface Infrastructure Value Configuration Capability Partnership P 3 Infrastructure Management 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 F 1 F 2 V 1= 0, 847 V 2= 0, 805 p 1 = 40 F 11 p 2= 60 F 12 F 21 V 11= 0, 83 p 11= 90 v J= V 12= 1 p 12= 10 F 23 V 21= 0, 9 p 21= 50 V 22= 0, 75 p 22= 10 V 23= 0, 7 p 23= 40 S (p, x V, ) j 100 F 211 F 212 V 211= 1 v 21= F 22 30 x 1 + 10 x 0 + 60 x 1 = 0, 9 100 Brno p 211= 30 F 213 V 212= 0 p 212= 10 V 213= 1 p 213= 60 Dr. J. Withalm 14
Program and System Engineering PSE Requirements/6 Non Functional Requirements/Quality Characteristics § § § § Brno reliability functional performance user friendliness time behaviour consume behaviour maintainability portability Dr. J. Withalm 15
Program and System Engineering PSE 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 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 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 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 Brno Dr. J. Withalm 22
Program and System Engineering PSE Requirements/12 What’s 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 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. 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 KPA‘s 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 SE 3) Brno Dr. J. Withalm 26
Program and System Engineering PSE CMMI Maturity Levels (staged) Benefit Quality Each transition takes 1 -3 years ! predictable process consistent process disciplined process 1 Initial Risk Brno 2 Managed 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 l The process is ad hoc and generally based on improvisation (by developers and managers). l Procedures, if existing at all, are not being adhered to. l Strong dependency on individuals (“heroes”). l Product quality and performance very difficult to predict. l Product quality and functionality downgrading to meet deadlines, but deadlines are still exceeded. l The use of new technologies involves major risks. l During a crisis, guidelines/rules are often abandoned as unnecessarily complicating. Brno Dr. J. Withalm 28
Program and System Engineering PSE Characteristics of a mature process l Standardized process, defined and documented lhas been understood and accepted lis being applied lis “alive” l Visible support through management l Clear definition and understanding of roles and responsibilities l Well-established control – process compliance is being monitored and enforced l Consistent with the staff’s current way of working l Measurable and being measured l Supported by means of suitable technologies and tools Brno Dr. J. Withalm 29
Program and System Engineering PSE CMMI Process Areas Organizational Innovation and Deployment Causal 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 Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Brno Configuration Management Defined (3) Dr. Managed (2) 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 Brno l Manage the requirements of the project’s products and product components and identify inconsistencies between those requirements and the project plans and work products. l. Manage Requirements. l Establish and maintain plans that define project activities. l. Establish Estimates l. Develop a Project Plan l. Obtain Commitment to the Plan l Provide understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan l. Monitor Project against plan l. 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 Brno l Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting and configuration audits. l. Establish baselines l. Track and control changes l. Establish integrity Dr. J. Withalm 32
Program and System Engineering PSE Process Areas and Specific Goals of ML 3 (1) Requirement Development Technical Solution Brno l Produce and analyze customer, product and product component requirements. l. Develop customer requirements l. Develop product requirements l. Analyze and validate requirements l Design, develop and implement solutions to requirements. Solutions, designs and implementations encompass either singly or in combinations as appropriate. l. Select product component solutions l. Develop the design l. Implement product design Dr. J. Withalm 33
Program and System Engineering PSE Process Areas and Specific Goals of ML 3 (2) Product Integration Verification Brno l Assemble the product from the product components, ensure that the product - as integrated – works properly (whole functionality) and deliver the product. l. Prepare for product integration l. Ensure interface compatibility l. Assemble product components and deliver the product l Ensure that the selected work products meet their specified requirements. l. Prepare for verification l. Perform peer reviews l. Verify selected work products Dr. J. Withalm 34
Program and System Engineering PSE Process Areas and Specific Goals of ML 3 (3) Validation Organizational Process Focus Brno l Demonstrate that the product or product components fulfills its intended use when placed in its intended environment l. Prepare for validation l. Validate product or product components (must be suitable for use in their intended operating environment) l Plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets. l. Determine process improvement opportunities l. Plan and implement process improvement activities Dr. J. Withalm 35
Program and System Engineering PSE Assessments/ Certification history in general - 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 (Do. D) 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 Brno back up quality assurance current checks during the development process Dr. J. Withalm 36
Program and System Engineering PSE 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
Program and System Engineering PSE Assessments/ Certification history in general /3 connection SW-engineering - QA - 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 KPA‘s 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 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 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 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 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 Window § operations origin size open() close() move() display() 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 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 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 that‘s 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 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 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 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 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 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 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 Event. Manager suspend() flush() 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 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, you‘ll 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 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 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 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 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 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 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 display 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 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 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 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 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 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 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 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 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 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) 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 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 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 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 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 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 § you‘ll 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 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 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 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 object-oriented 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 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 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 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 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 time-ordering of messages 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 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 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. 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 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 Brno Dr. J. Withalm 95
Program and System Engineering PSE Architecture/5 vocabulary functionality behavior system assembly configuration management Design view Implementation view Use case view Process view performance scalability throughput 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 doesn‘t really specify the organisation of a software system § rather, it exists to specify the forces that shape the system‘s 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 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 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 system‘s 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 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 system‘s 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 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 system‘s 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 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 system‘s architecture § for testing, and for communicating among the stakeholders of the project Brno Dr. J. Withalm 125
Program and System Engineering PSE Software development life cycle/3 architecture-centric § Architecture-centric means that a system‘s architecture is used as a primary artifact for § conceptualising § constructing § managing § and evolving the system under development 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 system‘s 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 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 KPA‘s Brno Dr. J. Withalm 135
Program and System Engineering PSE Which UML Model will support us in which Key Process Area of CMMI UML-Models REQM CM RD TS PI VER VAL Use cases deployment State chart Interfaces Process and threads Events and signals components interactions collaborations 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 Brno Dr. J. Withalm 137
Program and System Engineering PSE REQM /2 § 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 §. 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. 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. § 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 Brno Dr. J. Withalm 142
Program and System Engineering PSE RD/4 (Establish a definition of required functionality) § 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 user’s environment using multiple techniques as appropriate 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. Brno Dr. J. Withalm 144
Program and System Engineering PSE TS/2 ( develop detailed alternative solution and selection criteria/ Evolve the operational concepts and scenarios/ Select the product-component solution that best satisfy the criteria established/ design the product or product component ) § Via use case establish different collaboration interaction, activity diagrams § It’s 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 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. Brno Dr. J. Withalm 146
Program and System Engineering PSE 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 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 Brno Dr. J. Withalm 149
Thank you for your attention! 3/18/2018 Brno Dr. J. Withalm
Скачать презентацию Software Modeling UML 3 18 2018 Brno Dr J Withalm
dcb84afe5f732a6970bd7889afa15aee.ppt