Presentation is loading. Please wait.

Presentation is loading. Please wait.

N. Kokash, Software Engineering

Similar presentations


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

1 N. Kokash, Software Engineering
Natallia Kokash Note that the book is misleadingly simple. Just reading the book is like learning to swim without getting wet. N. Kokash, Software Engineering

2 Unified Modeling Language (UML)
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 © SE, Lifecycle, Hans van Vliet

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 © SE, Lifecycle, Hans van Vliet

5 Two-dimensional process structure of RUP
N. Kokash, Software Engineering © SE, Lifecycle, Hans van Vliet

6 Prepare vision document and initial business case
Inception Elaboration Construction Transition 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)
Inception Elaboration Construction Transition 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
Inception Elaboration Construction Transition 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 N. Kokash, Software Engineering

9 Produce incremental ‘bug-fix’ releases
Inception Elaboration Construction Transition 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 Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change 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?
Lower Management Complexity Higher DOD weapon system National Air Traffic Control System Telecom switch Large-scale simulation Web-based on-line trading Enterprise information systems Web application Business spreadsheet Small scientific Embedded automotive Commercial compiler Technical N. Kokash, Software Engineering

13 Configurable processes
N. Kokash, Software Engineering

14 Configurable processes
N. Kokash, Software Engineering

15 RUP framework RUP Process Framework Light RUP Config.
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. N. Kokash, Software Engineering

16 Model Driven Architecture (MDA)
implementation maintenance Model Code transformation First termed MDD: Model-Driven Development: much better name, but the acronym already existed. N. Kokash, Software Engineering © SE, Lifecycle, Hans van Vliet

17 Essence of MDA © SE, Lifecycle, Hans van Vliet
Platform is e.g. .NET, CORBA, hardware topology, etc. One can then define a transformation (refinement) from the PIM to one or more platform specific models. E.g. Java, N. Kokash, Software Engineering © SE, Lifecycle, Hans van Vliet

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

22 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 Two processes result: domain engineering, and application engineering. N. Kokash, Software Engineering © SE, Lifecycle, Hans van Vliet

23 Process modeling We may describe a software-development process in the form of a “program” : function review(document, threshold): boolean; begin prepare-review; hold-review{document, no-of-problems); make-report; return no-of-problems < threshold end review; Here, the review process is described in terms of the activities that have to be done N. Kokash, Software Engineering © SE, Lifecycle, Hans van Vliet

24 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 This is the same review process, but now emphasis is on the states, and state transitions. This figures uses the UML notation for state diagrams N. Kokash, Software Engineering © SE, Lifecycle, Hans van Vliet

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

26 Petri-net view of the code review process
hold review update end from coding management scheduled code ready minutes code revised code next step Petri nets allow for the modeling of nondeterminism and parallellism. Petri nets have places (the circles), which are either marked or unmarked. A transition if a vertical line. Transitions have inputs and outputs, the arrows. If all input paces to a transition are marked, in may “fire”. All marks are then removed form the input places, and all output places are marked. So, in the above exmple, the review can only be held if the code is ready for review, and management has scheduled the review. N. Kokash, Software Engineering © SE, Lifecycle, Hans van Vliet

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) For example, the Petri-net type of models can be used to drive the review process, whereby testers automatically get a warning when certain code is ready, managers get information about testing time, number of bugs found, etc. N. Kokash, Software Engineering © SE, Lifecycle, Hans van Vliet

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 So what tends to be modeled are the “easy” parts. As for stages versus what is really done, see earlier slide with the numbers from Zelkowitz. N. Kokash, Software Engineering © SE, Lifecycle, Hans van Vliet

29 Modeling techniques Traditional modeling Object-oriented 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
N. Kokash, Software Engineering

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

34 What is an object? Modeling viewpoint: model of part of the world
Identity + state + behavior Philosophical viewpoint: existential abstractions Everything is an object Software engineering viewpoint: data abstraction Implementation viewpoint: structure in memory Formal viewpoint: state machine 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) Subnodes Artifacts (rectangles)
Device Node Execution Environment Node 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

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

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

53 State machines 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 N. Kokash, Software Engineering

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

55 Use case diagrams N. Kokash, Software Engineering

56 Interaction diagrams 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. N. Kokash, Software Engineering

57 Communication diagrams
N. Kokash, Software Engineering

58 Interaction overview diagrams
N. Kokash, Software Engineering

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

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

61 Timing diagrams: example
N. Kokash, Software Engineering

62 UML UML2 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) N. Kokash, Software Engineering

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

64 Meta-Object Facility N. Kokash, Software Engineering

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

66 XML example <BOOKS> <book id=“123” loc=“library”> <author>Hull</author> <title>California</title> <year> 1995 </year> </book> <article id=“555” ref=“123”> <author>Su</author> <title> Purdue</title> </article> </BOOKS> Purdue Books 555 123 California Su title author article book year 1995 ref loc=“library” Hull N. Kokash, Software Engineering

67 XML Metadata Interchange (XMI)
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. N. Kokash, Software Engineering

68 N. Kokash, Software Engineering

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

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

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

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


Download ppt "N. Kokash, Software Engineering"

Similar presentations


Ads by Google