Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Engineering Natallia Kokash 1 N. Kokash, Software Engineering.

Similar presentations

Presentation on theme: "Software Engineering Natallia Kokash 1 N. Kokash, Software Engineering."— Presentation transcript:

1 Software Engineering Natallia Kokash email: 1 N. Kokash, Software Engineering

2 Software Engineering 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) 2 N. Kokash, Software Engineering

3 Software Engineering 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 3 N. Kokash, Software Engineering

4 Software Engineering RUP phases 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 4 N. Kokash, Software Engineering Inception: establish scope, boundaries, critical use cases, candidate architectures, schedule and cost

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

6 Software Engineering 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 6 N. Kokash, Software Engineering InceptionElaborationConstructionTransition

7 Software Engineering 7 N. Kokash, Software Engineering 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 InceptionElaborationConstructionTransition

8 Software Engineering Complete requirements and design model Design, implement and test each component  Prototype system and involve end users  Incrementally evolve executable architecture to complete 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 8 N. Kokash, Software Engineering InceptionElaborationConstructionTransition

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

10 Software Engineering 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 10 N. Kokash, Software Engineering Develop IterativelyManage RequirementsUse Component ArchitecturesModel Visually (UML)Continuously Verify QualityManage Change

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

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

13 Software Engineering Configurable processes 13 N. Kokash, Software Engineering

14 Software Engineering Configurable processes 14 N. Kokash, Software Engineering

15 Software Engineering RUP framework 15 N. Kokash, Software Engineering Disciplined Well-documented Traceability CCB High ceremony Relaxed Little documentation Light process Low ceremony Waterfall Few risk, sequential Late integration and testing Iterative Risk driven Continuous integration and testing RUP Process Framework Light RUP Config. Large, more formal RUP Config. Average RUP Config.

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

17 Software Engineering Essence of MDA 17 N. Kokash, Software Engineering

18 Software Engineering Essence of MDA 18 N. Kokash, Software Engineering

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

20 Software Engineering 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. 20 N. Kokash, Software Engineering

21 Software Engineering 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, Sodius MDWorkbench,  SysML: Artisan Studio, .NET target: Aspectize, CodeFluent Entities,  Java Spring: SkyWay Builder, SpringRoo, Jaxio Celerio & SpringFuse CASE tools with MDE capabilities: ModelioSoft Modelio, NoMagic MagicDraw, Sparx System Enterprise Architect 21 N. Kokash, Software Engineering

22 Software Engineering Software Product Lines 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 22 N. Kokash, Software Engineering Two processes result: domain engineering, and application engineering.

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

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

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

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

27 Software Engineering 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) 27 N. Kokash, Software Engineering

28 Software Engineering 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 28 N. Kokash, Software Engineering

29 Software Engineering 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 29 N. Kokash, Software Engineering

30 Software Engineering 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 30 N. Kokash, Software Engineering

31 Software Engineering 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 31 N. Kokash, Software Engineering

32 Software Engineering Data-flow modeling 32 N. Kokash, Software Engineering External entity Process Flow Data store

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

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

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

36 Software Engineering UML diagram types 36 N. Kokash, Software Engineering

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

38 Software Engineering 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 38 N. Kokash, Software Engineering

39 Software Engineering 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 39 N. Kokash, Software Engineering

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

41 Software Engineering 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; 41 N. Kokash, Software Engineering

42 Software Engineering 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) 42 N. Kokash, Software Engineering

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

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

45 Software Engineering 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. 45 N. Kokash, Software Engineering

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

47 Software Engineering 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. 47 N. Kokash, Software Engineering

48 Software Engineering Deployment diagram 48 N. Kokash, Software Engineering Nodes (boxes)  Device Node  Execution Environment Node Subnodes Artifacts (rectangles)

49 Software Engineering 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. 49 N. Kokash, Software Engineering

50 Software Engineering Package diagram 50 N. Kokash, Software Engineering

51 Software Engineering Profile diagram Can define:  classes  stereotypes  data types  primitive types  enumerations 51 N. Kokash, Software Engineering

52 Software Engineering diagrams Graphical representations of workflows  rounded rectangles represent activities;  diamonds represent decisions;  bars represent the start (split) or end (join) of concurrent activities;  a black circle represents the start (initial state) of the workflow;  an encircled black circle represents the end (final state). 52 N. Kokash, Software Engineering

53 Software Engineering State machines 53 N. Kokash, Software Engineering Significantly enhanced realization of the finite automata Directed graphs in which nodes denote states and connectors denote state transitions Extended states Guard conditions Actions Stubs

54 Software Engineering State machines: global and expanded views 54 N. Kokash, Software Engineering

55 Software Engineering Use case diagrams 55 N. Kokash, Software Engineering

56 Software Engineering Communication diagram shows the interactions between objects or parts in terms of sequenced messages. Interaction overview diagram provides an overview in which the nodes represent communication diagrams. Sequence diagram shows how objects communicate with each other in terms of a sequence of messages. Timing diagrams are specific types of interaction diagram where the focus is on timing constraints. 56 N. Kokash, Software Engineering Interaction diagrams

57 Software Engineering 57 N. Kokash, Software Engineering Communication diagrams

58 Software Engineering Interaction overview diagrams 58 N. Kokash, Software Engineering

59 Software Engineering Sequence diagrams 59 N. Kokash, Software Engineering Consist of:  Entities (components or objects, any order)  Lifespans  Messages (synchronous & asynchronous)

60 Software Engineering Timing diagrams Consists of:  Lifelines  State/condition lifelines  Duration constraints  Time constraints Destruction occurrence 60 N. Kokash, Software Engineering

61 Software Engineering Timing diagrams: example 61 N. Kokash, Software Engineering

62 Software Engineering UML  ArgoUML (closely follows the UML standard)  Umbrello UML Modeller  ATL (transform UML models into other models)  … UML2  BOUML (fast)  Eclipse UML2 Tools (not all diagrams supported)  StarUML (not under active development)  … 62 N. Kokash, Software Engineering

63 Software Engineering Meta-modeling Analysis, construction and development of the frames, rules, constraints, models and theories applicable and useful for modeling a predefined class of problems. 63 N. Kokash, Software Engineering

64 Software Engineering Meta-Object Facility 64 N. Kokash, Software Engineering

65 Software Engineering Extensible Markup Language (XML) Set of rules for encoding documents containing structured information in machine-readable form Markup language much like HTML Designed to carry data, not to display data XML tags are not predefined. You must define your own tags XML is designed to be self-descriptive 65 N. Kokash, Software Engineering

66 Software Engineering XML example Hull California 1995 Su Purdue 66 N. Kokash, Software Engineering

67 Software Engineering Exchanging metadata information via XML The most common use is an interchange format for UML (although it can be used for serialization of models of other languages) XMI is a way to save UML models in XML More generally, XMI shows how to save any MOF-based meta-model in XML Ability to move UML models between tools XMI doesn’t (yet) specify how to record graphical information; tools do this differently. 67 N. Kokash, Software Engineering XML Metadata Interchange (XMI)

68 Software Engineering 68 N. Kokash, Software Engineering

69 Software Engineering Programs that can open XMI files 69 N. Kokash, Software Engineering

70 Software Engineering Modeling processes  Focus on control of the development process  Each situation requires its own approach  Help with reuse and maintenance Modeling notations  Traditional  UML diagrams 70 N. Kokash, Software Engineering

71 Software Engineering Read chapters 3.3-3.9, 10 Design the Image2UML system using UML  use case, class, activity and statechart diagrams 71 N. Kokash, Software Engineering

72 Software Engineering Software Engineering (3 rd Ed.) 1. Introduction 2. Introduction to Software Engineering Management 3. The Software Life Cycle Revisited 4. Configuration Management 5. People Management and Team Organization 6. On Managing Software Quality 7. Cost Estimation 8. Project Planning and Control 9. Requirements Engineering 10. Modeling 11. Software Architecture 12. Software Design 13. Software Testing 14. Software Maintenance 17. Software Reusability 18. Component-Based Software Engineering 19. Service Orientation 20. Global Software Development 72 N. Kokash, Software Engineering

Download ppt "Software Engineering Natallia Kokash 1 N. Kokash, Software Engineering."

Similar presentations

Ads by Google