1 / 112

Software Modeling, UML

Software Modeling, UML. 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. Definitions/1.

nellie
Download Presentation

Software Modeling, UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Modeling, UML Brno Dr.J. Withalm

  2. 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 Dr. J. Withalm

  3. 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 Dr. J. Withalm

  4. 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? Dr. J. Withalm

  5. 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. Dr. J. Withalm

  6. Needs and Requirements • Identified needs must be transformed into requirements. • However, a product that satisfies requirements does not always satisfies needs. Dr. J. Withalm

  7. 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. Dr. J. Withalm

  8. QUALITY IN USE CONCEPTSStates – System Model Effects Needs QIU Current States Goal States Realized States Current System Proposed System Developed System Cause Dr. J. Withalm

  9. QIU Definition and CharacteristicsISO/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. Dr. J. Withalm

  10. Requirements/1 • Business oriented requirements • Functional requirements • Non functional requirements Dr. J. Withalm

  11. Requirements/2How to measure the fulfillment Dr. J. Withalm

  12. Requirements/3How to establish Business Strategies Dr. J. Withalm

  13. P1 Product Vision&Strategy P4 Financial Aspects P2 Customer Interface P3 Infrastructure Management Requirements/4How to establish Business Models Dr. J. Withalm

  14. Requirements/5Assessment Tree F V= 0,8218 p= 100 F 1 V 1= 0,847 p 1 = 40 F 2 V2= 0,805 p 2= 60 F 11 V11= 0,83 p 11= 90 F 12 V12= 1 p 12= 10 F 21 V21= 0,9 p 21= 50 F 22 V22= 0,75 p 22= 10 F 23 V23= 0,7 p 23= 40 • (p, x V,) • j vJ= 100 F 211 V211= 1 p 211= 30 F 212 V212= 0 p 212= 10 F 213 V213= 1 p 213= 60 v 21= 30 x 1 + 10 x 0 + 60 x 1 = 0,9 100 Dr. J. Withalm

  15. Requirements/6Non Functional Requirements/Quality Characteristics • reliability • functional performance • user friendliness • time behaviour • consume behaviour • maintainability • portability Dr. J. Withalm

  16. Requirements/6Action in SEM phases concerning quality evaluation Application of SEM Quality Evaluation Definition of quality objectives Direction for technical and quality assurance activities Examination if quality objectives are reached SEM Phases Initiation Study System Design Detailed Design Implementation Integration System Test Acceptance Dr. J. Withalm

  17. Requirements/7SEM Software Quality Evaluation Definition • Quality characteristics • Subcharacteristics List of criteria / checklists Evaluation procedures Dr. J. Withalm

  18. back up Requirements/10Evaluation Procedures • measuring • point scaling system • evaluation tree(functional performance) • project specific procedures Dr. J. Withalm

  19. Requirements/10Structuring of quality costs Quality related costs Error prevention cost Test costs Error costs Internal/external Cost to be conform to requirements Costs to be non conform to requirements Process related costs Dr. J. Withalm

  20. Requirements/11Why 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 Dr. J. Withalm

  21. Requirements/12What’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 Dr. J. Withalm

  22. Requirements/13And 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. Dr. J. Withalm

  23. 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 Dr. J. Withalm

  24. 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) Dr. J. Withalm

  25. continuouslyimproving process Benefit 5Optimizing Quality Risk process control 4 Quantitatively Managed predictable process quantitative process management 3Defined consistentprocess process definition 2Managed disciplined process basic projectmanagementand control 1Initial CMMI Maturity Levels (staged) Each transition takes1-3 years ! Dr. J. Withalm

  26. 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. Dr. J. Withalm

  27. 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 staff’s current way of working • Measurable and being measured • Supported by means of suitable technologies and tools Dr. J. Withalm

  28. Organizational Innovation and Deployment Causal Analysis & Resolution Optimizing (5) CMMI Process Areas Quantitative Process Management Software Quality Management Quantitatively 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 Defined (3) Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management Managed (2) Dr. J. Withalm

  29. Manage the requirements of the project’s products and product components and identify inconsistencies between those requirements and the project plans and work products. • Manage Requirements. Requirements Management Project Planning • Establish and maintain plans that define project activities. • Establish Estimates • Develop a Project Plan • Obtain Commitment to the Plan Project Monitoring and Control • 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 • Monitor Project against plan • Manage corrective actions to closure Process Areas and Specific Goals of ML 2 (1) Dr. J. Withalm

  30. 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 Configuration Management Process Areas and Specific Goals of ML 2 (3) Dr. J. Withalm

  31. Requirement Development • 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 Technical Solution Process Areas and Specific Goals of ML 3 (1) Dr. J. Withalm

  32. 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 • Ensure that the selected work products meet their specified requirements. • Prepare for verification • Perform peer reviews • Verify selected work products Verification Process Areas and Specific Goals of ML 3 (2) Dr. J. Withalm

  33. 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) • 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. • Determine process improvement opportunities • Plan and implement process improvement activities Organizational Process Focus Process Areas and Specific Goals of ML 3 (3) Dr. J. Withalm

  34. back up 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 (DoD) starts with QA, which is also checked with audits (AQAP) - Siemens starts in 1980 with QA system (CSA) to get through audits quality validationquality assurance sample audits on the current checks during finished product the development process Dr. J. Withalm

  35. back up Assessments/ Certification history in general/2 - 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 Dr. J. Withalm

  36. - 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 Assessments/ Certification history in general /3connection SW-engineering - QA Dr. J. Withalm

  37. 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 Dr. J. Withalm

  38. 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 Dr. J. Withalm

  39. 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 Dr. J. Withalm

  40. 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 2001-10-01 Dr. J. Withalm

  41. Structural things 2classes/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 Dr. J. Withalm

  42. Structural things/3classes/2 • Graphically, a class is rendered as a rectangle, usually including its • name • attributes • operations Window origin size open() close() move() display() Dr. J. Withalm

  43. Structural things/4interfaces/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 Dr. J. Withalm

  44. ISpelling Structural things/5interfaces/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 Dr. J. Withalm

  45. Structural things/6collaboration/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 Dr. J. Withalm

  46. Structural things/7collaboration/2 • Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name Chain ofresponsibility Dr. J. Withalm

  47. Structural things/8use 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 Dr. J. Withalm

  48. Structural things/9use cases/2 • Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name place order Dr. J. Withalm

  49. 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 Dr. J. Withalm

  50. Structural things/11active 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 Dr. J. Withalm

More Related