Download
software engineering n.
Skip this Video
Loading SlideShow in 5 Seconds..
Software Engineering PowerPoint Presentation
Download Presentation
Software Engineering

Software Engineering

10 Views Download Presentation
Download Presentation

Software Engineering

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Software Engineering Natallia Kokash email: nkokash@liacs.nl N. Kokash, Software Engineering

  2. Modeling processes • Rational Unified Process (RUP) • Model Driven Architecture (MDA) • Software product lines • Process modeling • Modeling techniques • Entity-relationship diagrams • Finite state machines • Data flow diagrams • Class-responsibility-collaboration cards • Unified Modeling Language (UML) N. Kokash, Software Engineering

  3. Rational Unified Process (RUP) • Iterative approach for object-oriented systems • Strongly embraces use cases for modeling requirements • Tool-supported (UML-tools, ClearCase) • History • Based on Objectory process by Jacobson • Formalized by Kruchten (1998) • Part of IBM Rational Method Composer N. Kokash, Software Engineering

  4. RUP phases • Inception: establish scope, boundaries, critical use cases, candidate architectures, schedule and cost Elaboration: foundation of architecture, establish tool support, get al use cases Construction: manufacturing process, one or more releases Transition: release to user community, often several releases N. Kokash, Software Engineering

  5. Two-dimensional process structure of RUP N. Kokash, Software Engineering

  6. Prepare vision document and initial business case • Include risk assessment and resource estimate • Develop high-level project requirements • Initial use-case and domain models (10-20% complete) • Manage project scope • Reduce risk by identifying all key requirements • Acknowledge that requirements will change • Manage change, use iterative process N. Kokash, Software Engineering

  7. Detail requirements as necessary (~80% complete) • Less essential requirements may not be fleshed out • Produce an executable and stable architecture • Define, implement and test interfaces of major components • Identify dependencies on external components and systems. Integrate shells/proxies of them • Implement some key components (roughly 10% of code) • Drive architecture with key use cases • 20% of use cases drive 80% of the architecture • Design, implement and test key scenarios for use cases • Verify architectural qualities • Stress test (reliability), load test (scalability and performance) • Continuously assess business case, risk profile and development plan N. Kokash, Software Engineering

  8. Complete requirements and design model • Design, implement and test each component • Prototype system and involve end users • Incrementally evolve executable architecture tocomplete system • Build daily or weekly with automated build process • Test each build • Automate regression testing • Load and stress test to ensure architectural integrity • Deliver fully functional software (beta release) • Includes training material, user and deployment documentation • Produce release descriptions N. Kokash, Software Engineering

  9. Produce incremental ‘bug-fix’ releases Update user manuals and deployment documentation Update release descriptions Execute cut-over Conduct “post-mortem” project analysis N. Kokash, Software Engineering

  10. Key principles and best practices • Develop only what is necessary • Lean process, agility • Minimize paperwork • Be flexible • Requirements, plan, usage of people, etc… • Learn from earlier mistakes • Feedback loops • Process improvement • Revisit risks regularly • Establish objective, measurable criteria for progress • Automate • Support process with software development tools N. Kokash, Software Engineering

  11. Structured processes Roles Artifacts Activities Guidelines Templates Tool mentors N. Kokash, Software Engineering

  12. Can a single process fit all these? Higher Technical Complexity DOD weapon Embedded system automotive Telecom switch National Air Traffic application Commercial Control System compiler Lower Higher Management Management Complexity Complexity Large-scale simulation Small scientific Enterprise simulation Web information application systems Web-based on-line trading system Business spreadsheet Lower N. Kokash, Software Engineering Technical Complexity

  13. Configurable processes N. Kokash, Software Engineering

  14. Configurable processes N. Kokash, Software Engineering

  15. RUP framework Waterfall Few risk, sequential Late integration and testing Relaxed Little documentationLight processLow ceremony Disciplined Well-documentedTraceabilityCCB High ceremony RUP Process Framework Light RUP Config. Large, more formal RUP Config. Average RUP Config. Iterative Risk drivenContinuous integration and testing N. Kokash, Software Engineering

  16. Model Driven Architecture (MDA) Model maintenance implementation transformation Code maintenance N. Kokash, Software Engineering

  17. Essence of MDA N. Kokash, Software Engineering

  18. Essence of MDA N. Kokash, Software Engineering

  19. Example of MDA Framework for the development of new financial applications N. Kokash, Software Engineering

  20. MDA tool types Creation: elicit initial models and/or edit derived models. Analysis: check models for completeness, inconsistencies, or error and warning conditions, calculate metrics for the model. Transformation: transform models into other models or into code and documentation. Composition: compose (i.e., merge) several source models. Test: test models using model-based testing approaches Simulation: simulate the execution of a system represented by a given model. Metadata management: handle the general relations between different models and the mutual relations between these models. Reverse engineering: transform particular legacy or information artifact portfolios into full-fledged models. N. Kokash, Software Engineering

  21. MDA Software Examples • M2M transformation: ActifSource, AndroMDA, Mia Software Mia-Generation & Mia-Transformation, • Eclipse Modeling Project: ATL, QVT (Queries/Views/Transformations), xpand/xtend; • UI design tools: Eclipse E4/XWT, redView, wazaabi • Application builders: BluAge, Mendix, Outsystems Agile Platform, SodiusMDWorkbench, • SysML: Artisan Studio, • .NET target: Aspectize, CodeFluent Entities, • Java Spring: SkyWay Builder, SpringRoo, JaxioCelerio & SpringFuse • CASE tools with MDE capabilities: ModelioSoftModelio, NoMagicMagicDraw, Sparx System Enterprise Architect N. Kokash, Software Engineering

  22. Software Product Lines • Two processes result: domain engineering, and application engineering. Developers are not inclined to make a maintainable and reusable product, it has additional costs. This viewpoint is changed somewhat if the product family is the focus of attention rather than producing a single version of a product N. Kokash, Software Engineering

  23. Process modeling • We may describe a software-development process in the form of a “program” : functionreview(document, threshold): boolean; begin prepare-review; hold-review{document, no-of-problems); make-report; return no-of-problems < threshold end review; N. Kokash, Software Engineering

  24. State diagram of the code review process ready for the next step submit coding ready review re-review make prepare do done report ready ready report N. Kokash, Software Engineering

  25. Example: Framework to generate Domain Specific Languages N. Kokash, Software Engineering

  26. Petri-net view of thecode review process code ready code update hold review from end revised code next step coding from management minutes scheduled N. Kokash, Software Engineering

  27. Purposes of process modeling Facilitates understanding and communication by providing a shared view of the process Supports management and improvement; it can be used to assign tasks, track progress, and identify trouble spots Serves as a basis for automated support (usually not fully automatic) N. Kokash, Software Engineering

  28. Caveats of process modeling Not all aspects of software development can be caught in an algorithm A model is a model, thus a simplification of reality Progression of stages differs from what is actually done Some processes (e.g. learning the domain) tend to be ignored No support for transfer across projects N. Kokash, Software Engineering

  29. Modeling techniques • Traditional modeling • Entity-relationship diagrams (ER) • Finite state machines (FSM) • Data-flow models • Class-responsibility-collaboration (CRC) • Object-oriented modeling • Variety of UML diagrams N. Kokash, Software Engineering

  30. Entity-relationship modeling Entity: distinguishable object of some type Entity type: type of a set of entities Attribute value: piece of information (partially) describing an entity Attribute: type of a set of attribute values Relationship: association between two or more entities N. Kokash, Software Engineering

  31. Finite State Machines (FSM) • Models a system in terms of a finite number of states and transitions between those states • Often depicted as state transition diagrams: • Each state is a bubble • Each transition is a labeled arc from one state to another • Large system  large diagram N. Kokash, Software Engineering

  32. Data-flow modeling External entity Flow Process Data store http://www.yourdon.com/strucanalysis/wiki/index.php?title=Chapter_9 N. Kokash, Software Engineering

  33. Class-responsibility-collaboration N. Kokash, Software Engineering

  34. What is an object? • Software engineering viewpoint: data abstraction • Implementation viewpoint: structure in memory • Formal viewpoint: state machine • Modeling viewpoint: model of part of the world • Identity + state + behavior • Philosophical viewpoint: existential abstractions • Everything is an object N. Kokash, Software Engineering

  35. Unified Modeling Language (UML) • Object Management Group (OMG) consortium • Latest version: UML 2.2 • 14 diagram types: • Static diagrams • Dynamic diagrams • Often loose semantics N. Kokash, Software Engineering

  36. UML diagram types N. Kokash, Software Engineering

  37. UML Use in Practice N. Kokash, Software Engineering

  38. Structure diagrams Class diagram describes the structure of a system (classes, attributes, methods) and relationships among the classes. Component diagram shows the dependencies among system components. Composite structure diagram describes the internal structure of a class and collaborations among its parts Deployment diagram describes the hardware used in implementations and execution environments Object diagram shows a complete or partial view of the structure of a modeled system at a specific time. Package diagram shows the dependencies among logical groupings. Profile diagram operates at the meta-model level to show stereotypes as classes and profiles as packages N. Kokash, Software Engineering

  39. diagram • Used both for conceptual and detailed modeling • Classes, interfaces: class name, attributes, methods • Visibility: public (+), private (-), protected (#), package (~), derived (/), static • Relationships(links) • Instance-level: association, aggregation, composition • Class-level: generalization, realization • General: dependency N. Kokash, Software Engineering

  40. Association Bidirectional Unidirectional Reflexive Aggregation Composition N. Kokash, Software Engineering

  41. Aggregation and composition Aggregation is a variant of the "has a" or association relationship; Composition is a stronger variant of the “has a“ or association relationship (assuming life cycle dependency); Aggregation is more specific than association; Composition is more specific than aggregation; N. Kokash, Software Engineering

  42. Generalization "is a“ relationship indicates that one of the two related classes (subclass) is considered to be a specialized form of the other (super type) N. Kokash, Software Engineering

  43. Realization • Interface = class with abstract methods • One model element (the client) realizes (implements or executes) the behavior that the other model N. Kokash, Software Engineering

  44. Component diagrams Like class diagram (stereotype <<component>>) Way to identify larger entities One way to depict a module view Components are connected by interfaces N. Kokash, Software Engineering

  45. Behavioral diagrams Activity diagram describes the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control. UML state machine diagram describes the states and state transitions of the system. Use case diagram describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases. N. Kokash, Software Engineering

  46. Composite structure diagrams • Can be used to show: • Internal structure of a class • Class interactions with environment through ports • Possible collaborations of class parts N. Kokash, Software Engineering

  47. Composite structure diagram concepts Part is a role played at runtime by one or more instances of a class. Port is an interaction point that can be used to connect structured classifiers Connector binds two or more entities together Collaboration defines roles that class instances play Structured classifier represents a class whose behavior can be described through interactions between parts. Encapsulated classifier is a type of structured classifier that contains ports. N. Kokash, Software Engineering

  48. Deployment diagram • Nodes (boxes) • DeviceNode • ExecutionEnvironmentNode • Subnodes • Artifacts (rectangles) N. Kokash, Software Engineering

  49. Object diagram Some set of object instances, attributes and links A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time. N. Kokash, Software Engineering

  50. Package diagram N. Kokash, Software Engineering