Software Engineering

Software Engineering Natallia Kokash email: nkokash@liacs.nl N. Kokash, 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) N. Kokash, 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 N. Kokash, Software Engineering

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

Two-dimensional process structure of RUP N. Kokash, 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 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 N. Kokash, Software Engineering

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

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

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

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

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

Configurable processes N. Kokash, Software Engineering

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

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

Essence of MDA N. Kokash, Software Engineering

Example of MDA Framework for the development of new financial applications N. Kokash, 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. N. Kokash, 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, 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

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

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

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

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

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

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

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

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

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

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

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

Class-responsibility-collaboration N. Kokash, Software Engineering

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

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

UML diagram types N. Kokash, Software Engineering

UML Use in Practice N. Kokash, 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 N. Kokash, 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 N. Kokash, Software Engineering

Association Bidirectional Unidirectional Reflexive Aggregation Composition N. Kokash, 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; N. Kokash, 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) N. Kokash, Software Engineering

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

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

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

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

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

Deployment diagram • Nodes (boxes) • DeviceNode • ExecutionEnvironmentNode • Subnodes • Artifacts (rectangles) N. Kokash, 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. N. Kokash, Software Engineering

Package diagram N. Kokash, Software Engineering

Software Engineering