Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Software Engineering - chp3- design

Software Design

  • Be the first to comment

Software Engineering - chp3- design

  1. 1. MedTech Chapter 3 – Software Design Specificities of the design step, UML modeling Dr. Lilia SFAXI Slide 1 MedTech – Mediterranean Institute of Technology Software Engineering MedTech
  2. 2. MedTech INTRODUCTION TO SOFTWARE DESIGN Design Dr. Lilia SFAXI Slide 2
  3. 3. MedTech Software Design: Definition • Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software. • A blueprint is a reproduction of a technical drawing, documenting an architecture or an engineering design • Initially, the blueprint depicts a holistic view of software. Dr. Lilia SFAXI Slide 3 Introduction to Software Design
  4. 4. MedTech Process of Design Engineering • During the design process the software specifications are transformed into design models • Models describe the details of the data structures, system architecture, interface, and components. • Each design product is reviewed for quality before moving to the next phase of software development. • At the end of the design process a design model and specification document is produced. • This document is composed of the design models that describe the data, architecture, interfaces and components. Dr. Lilia SFAXI Slide 4 Introduction to Software Design
  5. 5. MedTech Design Specification Models Dr. Lilia SFAXI Slide 5 Introduction to Software Design Entity- Relationship Diagram Data Flow Diagram State-Transition Diagram Data Dictionary Process Specification (PSPEC) Control Specification (CSPEC) Data Object Description Data Design Architectural Design Interface Design Procedural Design THE DESIGN MODELTHE ANALYSIS MODEL
  6. 6. MedTech Data Design • Created by transforming the analysis information model (data dictionary and ERD) into data structures required to implement the software. • Part of the data design may occur in conjunction with the design of software architecture. • More detailed data design occurs as each software component is designed. Dr. Lilia SFAXI Slide 6 Introduction to Software Design Data Dictionary
  7. 7. MedTech Data Design • Created by transforming the analysis information model (data dictionary and ERD) into data structures required to implement the software. • Part of the data design may occur in conjunction with the design of software architecture. • More detailed data design occurs as each software component is designed. Dr. Lilia SFAXI Slide 7 Introduction to Software Design Entity Relationship Diagram
  8. 8. MedTech Architectural Design • Defines : • The relationships among the major structural elements of the software • The “design patterns” than can be used to achieve the requirements that have been defined for the system • The constraints that affect the way in which the architectural patterns can be applied. • It is derived from the system specification, the analysis model, and the subsystem interactions defined in the analysis model (DFD). Dr. Lilia SFAXI Slide 8 Introduction to Software Design Dataflow Diagram
  9. 9. MedTech Architectural Design • Defines : • The relationships among the major structural elements of the software • The “design patterns” than can be used to achieve the requirements that have been defined for the system • The constraints that affect the way in which the architectural patterns can be applied. • It is derived from the system specification, the analysis model, and the subsystem interactions defined in the analysis model (DFD). Dr. Lilia SFAXI Slide 9 Introduction to Software Design MVP Design Pattern
  10. 10. MedTech Interface Design • Describes how the software elements communicate with each other, with other systems and with human users • Much of the necessary information required is provided by the data flow and control flow diagrams Dr. Lilia SFAXI Slide 10 Introduction to Software Design Control Flow Diagram
  11. 11. MedTech Procedural/Component-level Design • Created by transforming the structural elements defined by the software architecture into procedural descriptions of software components • Uses information obtained from : • Process specification (PSPEC) • Use cases, FlowCharts, Activity Diagrams… • Control specification (CSPEC) • State Transition Diagram (STD), Decision tables … Dr. Lilia SFAXI Slide 11 Introduction to Software Design State Transition Diagram
  12. 12. MedTech DESIGN FUNDAMENTAL CONCEPTS Design Dr. Lilia SFAXI Slide 12
  13. 13. MedTech Fundamental Concepts • Abstraction: Data, procedure, control • Architecture: Overall structure of the software • Patterns: Convey the essence of a proven design solution • Modularity: Compartimentalization of data and function • Information Hiding: Controlled interfaces • Functional Independance: Single-minded function and low coupling • Refinement: Elaboration of detail for all abstractions • Refactoring: Reorganization technique that simplifies the design Dr. Lilia SFAXI Slide 13 Software Design
  14. 14. MedTech Fundamental Concepts • Abstraction • Allows designers to focus on solving a problem without being concerned about irrelevant lower level details • Procedural Abstraction: named sequence of events • Data Abstraction: named collection of data objects • Refinement • Process of elaboration where the designer provides successively more details for each design component • Modularity • Degree to which the software can be understood by examining its components independently of one another Dr. Lilia SFAXI Slide 14 Software Design
  15. 15. MedTech Fundamental Concepts: Patterns • A common solution to a common problem in a given context • High level patterns for organizing software: architectural styles • Low level patterns for describing details : • Creational Patterns: Builder, factory, prototype, singleton… • Structural Patterns: Adapter, bridge, composite, façade… • Behavioral Patterns: Command, interpreter, oterator, mediator... • Design Patterns • Enable a designer to determine wheter the pattern: • Is applicable to the current work • Can be reused • Can serve as a guide for developing a similar but functionally or structurally different pattern Dr. Lilia SFAXI Slide 15 Software Design
  16. 16. MedTech Fundamental Concepts: Information Hiding • A good split of modules is when modules communicate with one another with only the information necessary to achieve the software function • Enforces access constraints to • Procedural details with a module • Local data structure used by that module • Benefits • Reduces the likelihood of “side effects” • Limits the global impact of local design decisions • Emphasizes communication through controlled interfaces • Discourages the use of global data • Leads to encapsulation—an attribute of high quality design • Results in higher quality software Dr. Lilia SFAXI Slide 16 Software Design
  17. 17. MedTech Fundamental Concepts: Functional Independence • Cohesion • Degree to which a module performs one and only one function • All elements of component are directed toward performing the same task Dr. Lilia SFAXI Slide 17 Software Design Functional Sequential Communicational Procedural Temporal Logical Coincidental Low Cohesion High Cohesion
  18. 18. MedTech Fundamental Concepts: Functional Independence • Coupling • Degree to which a module is connected to other modules in the system • Two components can be dependant in many ways: • References made from one to another • Amount of data passed from one to another • Amount of control one has over the other • … Dr. Lilia SFAXI Slide 18 Software Design Content Common External Control Stamp Data Uncoupled Low Cohesion High Cohesion
  19. 19. MedTech Fundamental Concepts: Refinement • Refinement is a process of elaboration • It is a top-down design strategy • A program is developed by successfully refining levels of procedural details Dr. Lilia SFAXI Slide 19 Software Design Open Door walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat
  20. 20. MedTech Fundamental Concepts: Refactoring • ”Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure”, M. Fowler • Refactoring a software means examining the existing design for: • Redundancy • Unused design elements • Inefficient or unnecessary algorithms • Poorly constructed or inappropriate data structures • Any other design failure that can be corrected to yield a better design Dr. Lilia SFAXI Slide 20 Software Design
  21. 21. MedTech VISUAL MODELING WITH UML Design Dr. Lilia SFAXI Slide 21
  22. 22. MedTech Visual Modeling • Modeling captures essential parts of the system • Visual modeling is modeling using standard graphical notations • Visual modeling • Captures business process from user’s perspective • Is a communication tool between the business domain and the computer domain • Manages complexity using refinement techniques • Defines software architecture • Promotes reuse Dr. Lilia SFAXI Slide 22 Visual Modeling with UML
  23. 23. MedTech UML • Unified Modeling Language • Standard language for visualizing, specifying, constructing and documenting the artifacts of a software system. • Combines notions from: • Data modeling concepts (entity relationship diagrams) • Business modeling (workflow) • Object modeling • Component modeling • Can be used with all processes, throughout the development lifecycle, and across different implementation technologies Dr. Lilia SFAXI Slide 23 Visual Modeling with UML
  24. 24. MedTech UML Usage • UML may be used to: • Display the boundary of a system and its major functions using use cases and actors • Illustrate use case realizations with interaction diagrams • Represent a static structure of a system using class diagrams • Model the behaviour of objects with state transition diagrams • Reveal the physical implementation architecture with component and deployment diagrams • Extend the basic functionalities with stereotypes • UML is NOT: • A programming language • Highly formal language for theorem proving Dr. Lilia SFAXI Slide 24 Visual Modeling with UML
  25. 25. MedTech Why Unified? • Across historical methods and notations • Combines the commonly accepted concepts from many object-oriented methods • Across the development lifecycle • Seamless from requirements to deployment • Across application domains • Models most application domains, including large, complex, real-time, distributed, data or computation intensive,… • Across implementation languages and platforms • Usable for systems implemented in various languages and platforms • Across development processes • Usable as the modeling language underlying mist existing or new development processes • Supports iterative, incremental, agile,... Models • Across internal concepts • Represents internal relationships in a broad way applicable to many situations Dr. Lilia SFAXI Slide 25 Visual Modeling with UML
  26. 26. MedTech UML Views • View: A subset of UML modeling constructs that represents one aspect of a system • Views are divided into areas • Structural classification • Things in the system and their relationships to other things • Things are modelized using “classifiers” (class, use case, actor, node…) • Dynamic behavior • Behavior of a system or other classifier over time • Can be described as a series of changes to snapshots of the system drawn from the static view • Physical layout • Computational resources in the system and deployment of artifacts on them • Model management • Organization of the models into hierarchical units Dr. Lilia SFAXI Slide 26 Visual Modeling with UML
  27. 27. MedTech UML Views Area View Diagram Structural Static View Class Diagram Design View Internal Structure Collaboration Diagram Component Diagram Use Case View Use Case Diagram Dynamic State Machine View State Machine Diagram Activity View Activity Diagram Interaction View Sequence Diagram Communication Diagram Physical Deployment View Deployment Diagram Model Management Model Management View Package Diagram Profile Package Diagram Dr. Lilia SFAXI Slide 27 Visual Modeling with UML
  28. 28. MedTech UML DESIGN: USE CASE VIEW Design Dr. Lilia SFAXI Slide 28
  29. 29. MedTech Use Case View • Captures the behavior of a system, subsystem, class or coponent, as it appears to an outside user • Partitions the system’s functionality into transactions meaningful to actors, users of the system • Actors can be human, other computer systems or processes • The pieces of interactive functionalities are calles use cases • A use case describes an interaction with actors as a sequence of messages between the system and one or more actors Dr. Lilia SFAXI Slide 29 UML Design: Use Case View
  30. 30. MedTech Actor • Idealization of a role played by an external person, process or thing interacting with a system, subsystem or class • Characterizes th interactions that a class of outside user may have with the system • One physical user may be bound to multiple actors • Different users may be bound to the same actor definition • Each actor participates in one or more use cases by exchanging messages Dr. Lilia SFAXI Slide 30 UML Design: Use Case View
  31. 31. MedTech Use Case • Coherent unit of externally visible functionality provided by a classifier (subject), and expressed by sequences of messages exchanged by the subject and one or more actors of the system unit • Defines a piece of coherent behavior without revealing the internal structure of the subject • The execution of each use case is independent of the others • But its implementation may create implicit dependencies among them due to shared objects • The dynamics of a use case may be specified by • UML interactions: statechart diagrams, sequence diagrams, communication diagrams… • Informal text descriptions Dr. Lilia SFAXI Slide 31 UML Design: Use Case View
  32. 32. MedTech Use Case Diagram Dr. Lilia SFAXI Slide 32 UML Design: Use Case View
  33. 33. MedTech Use Case Relationships • Association • The communication path between an actor and a use case that it participates in • Extension • Relationship from an extension use case to a base use case • Specifies how the behavior defined for the extension use case can be inserted into that of the base use case • Inclusion • Relationship from a base use case to an inclusion use case • Specifies that the behavior defined for the inclusion use case is to be inserted into that of the base use case. • Use case generalization • Relationship between a general use case and a more specific use case that inherits and adds features to it Dr. Lilia SFAXI Slide 33 UML Design: Use Case View
  34. 34. MedTech Use Case Relationships: Example Dr. Lilia SFAXI Slide 34 UML Design: Use Case View
  35. 35. MedTech Use Case Relationships: Example Dr. Lilia SFAXI Slide 35 UML Design: Use Case View
  36. 36. MedTech Use Case Textual Description Dr. Lilia SFAXI Slide 36 UML Design: Use Case View
  37. 37. MedTech Use Case View: Case Study • We want to model a simplified system of the automatic teller machine (ATM), offering the following services: 1. Distribution of money to every holder of a smartcard via a card reader and a cash dispenser 2. Consultation of account balance, cash and cheque deposit facilities for bank customers who hold a smartcard from their bank 3. All transactions are made secure 4. It is sometimes necessary to refill the dispenser Dr. Lilia SFAXI Slide 37 UML Design: Use Case View
  38. 38. MedTech Use Case View: Proposition of Solution Dr. Lilia SFAXI Slide 38 UML Design: Use Case View
  39. 39. MedTech UML DESIGN: STATIC VIEW Design Dr. Lilia SFAXI Slide 39
  40. 40. MedTech Static View • Foundation of UML • Concepts that are meaningful in an application • Describes behaviral declarations, such as operations, without the details of their dynamic behaviour (described by the dynamic views) • Key elements: classifiers and relationships • Classifier • Modeling element that describes things containing values • Describes identity, state, behaviour, relationships and optionally the internal structure of the object • Relationships • Are defined between classifiers to represent associations, dependency, generalization, realization or usage Dr. Lilia SFAXI Slide 40 UML Design: Static View
  41. 41. MedTech Class Diagram • A picture of: • The classes in an OO system • Their fields and methods • Connections between the classes that interact or inherit from one another • It does NOT represent: • Details of how the classes interact with each other • Algorithmic details: how a particular behavior is implemented Dr. Lilia SFAXI Slide 41 UML Design: Static View
  42. 42. MedTech Classifiers • Class: Main classifier in the static view • Discrete concept within the application being modeled, representing things of a particular kind: physical, business, logical, application, computer or behavioral • Defines a set of objects that have state and behavior • State: described by attributes • Behavior: described by operations (methods) Dr. Lilia SFAXI Slide 42 UML Design: Static View
  43. 43. MedTech Classifiers • Interface • Description of the behavior of objects without giving their implementation or state • One or more class or component may realize an interface • Each class must implement the operations found in the interface • Data types • A primitive type: description of primitive values that lack identity (independent existence) • Include numbers and strings • Passed by value and immutable entities • Has no attributes, but may have operations, that do not modify the data values, but may return other values Dr. Lilia SFAXI Slide 43 UML Design: Static View
  44. 44. MedTech Class • Class name in top of the box • Write <<interface>> on top of interfaces’ names • Use italics for an abstract class name • Attributes (optional) • Should include all fields of the object • visiblity name : type [count] = defaultVal • Visiblity: • + public • # protected • - private • ~ package (default) • / derived (can be computed from other attributes) • Static attributes are underlined • Example • - balance : double = 0.00 Dr. Lilia SFAXI Slide 44 UML Design: Static View
  45. 45. MedTech Class • Operations / Methods (optional) • May omit trivial (get/set) methods, but never omit methods from an interface • Should not include inherited methods • visiblity name (param1:type, param2:type ): return_type • Visiblity: • + public • # protected • - private • ~ package (default) • Static methods are underlined • Example: • + distance(p1: Point, p2: Point): double Dr. Lilia SFAXI Slide 45 UML Design: Static View
  46. 46. MedTech Relationships • Association • Description of a connection among instances of classes • Dependency • Relationship between two model elements • Generalization • Relationship between a more specific and a more general description • Used for inheritance and polymorphic type declarations • Realization • Relationship between a specification and its implementation • Usage • A situation in which one element requires another for its correct functioning Dr. Lilia SFAXI Slide 46 UML Design: Static View
  47. 47. MedTech Association Dr. Lilia SFAXI Slide 47 UML Design: Static View
  48. 48. MedTech Association Class Dr. Lilia SFAXI Slide 48 UML Design: Static View
  49. 49. MedTech Association: Navigability Dr. Lilia SFAXI Slide 49 UML Design: Static View
  50. 50. MedTech Naming an Association Dr. Lilia SFAXI Slide 50 UML Design: Static View
  51. 51. MedTech Aggregation and Composition Dr. Lilia SFAXI Slide 51 UML Design: Static View • Aggregation: • Association that represents a part-whole relationship • Composition: • A stronger form of association • The composite has the sole responsibility for managing its parts • An object may belong to at most one composition
  52. 52. MedTech Generalization Dr. Lilia SFAXI Slide 52 UML Design: Static View • Taxonomic relationship between a more general description (parent) and a more specific description (child), that builds on it and extends it • Used for all classifiers • For classes, the terms superclass and subclass are used
  53. 53. MedTech Realization Dr. Lilia SFAXI Slide 53 UML Design: Static View • Connects a model elements (for ex. a class) to another model element (for ex. an interface) that supplies its behavioral specification, but not its structure or implementation
  54. 54. MedTech Dependency Dr. Lilia SFAXI Slide 54 UML Design: Static View • Indicates a semantic relationship between two or more model elements • Relates the model elements themselves, and doesn’t require a set of instances for its meaning • Indicates a situation where a change to the supplier element may require a change to the client element • Association and generalization are specific dependencies
  55. 55. MedTech Object Diagram Dr. Lilia SFAXI Slide 55 UML Design: Static View • A diagram of a snapshot, an image of the system at a point in time • Used as an example of the system
  56. 56. MedTech Static View: Case Study • We want to model a simplified system of flight reservation for a travel agency • These are the key sentences representing the needs of the business experts 1. Airline companies offer several flights 2. A flight is open to reservation and closed by the company 3. A client can book one or several flights, for different passengers 4. A reservation concerns a single flight and a single passenger 5. A reservation can be canceled or confirmed 6. A flight has a departure airport and an arrival airport 7. A flight has a date and time of departure, and a date and time of arrival 8. A flight can have stopovers in airports 9. A stopover has an arrival time and a departure time 10. Each airport services one or more towns Dr. Lilia SFAXI Slide 56 UML Design: Static View
  57. 57. MedTech Static View: Proposition of a Solution Dr. Lilia SFAXI Slide 57 UML Design: Static View
  58. 58. MedTech UML DESIGN: INTERACTION VIEW Design Dr. Lilia SFAXI Slide 58
  59. 59. MedTech Interaction View • Provides a holistic view of the behavior of an entire system • Describes how groups of objects collaborate in some behavior • Two kinds of diagrams: • Sequence diagram • Displays an interaction as a two-dimentional chart • The vertical dimension is the time axis • The horizontal dimension shows the roles that represent individual objects in the collaboration • Doesn’t show exact time intervals • Communication diagram • Shows interactions organized around the parts of a composite structure or the roles of a collaboration • Explicitly shows the relationships between the elements • Doesn’t show time as a separate dimension, just with sequence numbers Dr. Lilia SFAXI Slide 59 UML Design: Interaction View
  60. 60. MedTech Sequence Diagram vs. Communication Diagram Dr. Lilia SFAXI Slide 60 UML Design: Interaction View Sequence Diagram Communication Diagram
  61. 61. MedTech Sequence Diagram: Key Parts • Participant • Object or entity that acts in the sequence diagram • Can be an instance of a class, or an actor • Message • Communication between participant objects • A sequence diagram can start with an unattached “found message” arrow • Found message: message where the receiving event occurrence is known, but there is no known sending event occurrence Dr. Lilia SFAXI Slide 61 UML Design: Interaction View
  62. 62. MedTech Sequence Diagram: Objects • Objects are represented using squares with object type (class), optionally preceded by object name and a colon • If you want to write only the class name, without the object name, the colon is mandatory • The object’s lifeline is represented by a dashed vertical line Dr. Lilia SFAXI Slide 62 UML Design: Interaction View
  63. 63. MedTech Sequence Diagram: Messages • A message (method call) is indicated by a horizontal arrow to the object • A dashed arrow back indicates a return • There are different arrow heads for normal / asynchronous methods Dr. Lilia SFAXI Slide 63 UML Design: Interaction View
  64. 64. MedTech Sequence Diagram: Messages • The message name and arguments are written above the arrow Dr. Lilia SFAXI Slide 64 UML Design: Interaction View
  65. 65. MedTech Sequence Diagram: Lifetime • Creation • Arrow with new or create on it • An object created after the start of the scenario appears lower than the others • Deletion • An X at the bottom of object’s lifeline • Either deleted explicitely or implicitely (garbage collected) by the system Dr. Lilia SFAXI Slide 65 UML Design: Interaction View
  66. 66. MedTech Sequence Diagram: Activation • Activation • Thick box over object’s lifeline • Drawn when the object’s method is on the stack • Either the method is still running, or waiting for a response • Use nesting to represent recursion Dr. Lilia SFAXI Slide 66 UML Design: Interaction View
  67. 67. MedTech Sequence Diagram: Selections and Loops • Frame: box around part of a sequence diagram to indicate selection or loop • If : (opt) [condition] • If/else: (alt) [condition], separated by horizontal dashed line • Loop: (loop) [condition or items to loop over] Dr. Lilia SFAXI Slide 67 UML Design: Interaction View
  68. 68. MedTech Sequence Diagram: Linking Diagrams • If one sequence diagram is too large or refers to another diagram, indicate it with either: • An unfinished arrow and comment • A ”ref ” frame that names the other diagram Dr. Lilia SFAXI Slide 68 UML Design: Interaction View
  69. 69. MedTech Interaction View: Case Study • We have an order and are going to invoke a command on it to calculate its price. • To do that, the order needs to look at all the line items on the order and determine their prices, which are based on the pricing rules of the order line's products. • Having done that for all the line items, the order then needs to compute an overall discount, which is based on rules tied to the customer. Dr. Lilia SFAXI Slide 69 UML Design: Interaction View
  70. 70. MedTech Interaction View: Proposition of a Solution (1) Dr. Lilia SFAXI Slide 70 UML Design: Interaction View
  71. 71. MedTech Interaction View: Proposition of a Solution (2) Dr. Lilia SFAXI Slide 71 UML Design: Interaction View
  72. 72. MedTech UML DESIGN: ACTIVITY VIEW Design Dr. Lilia SFAXI Slide 72
  73. 73. MedTech Activity View • Activity: Graph of nodes and flows that shows the flow of control and data through the steps of a computation • Steps can be either concurrent or sequential • Can involve synchronization and branching constructs • Activity contains: • Activity nodes: a step in the workflow • Nodes are connected by control flows and data flows • Activity is defined in an activity diagram Dr. Lilia SFAXI Slide 73 UML Design: Activity View
  74. 74. MedTech Activity Diagram Dr. Lilia SFAXI Slide 74 UML Design: Activity View
  75. 75. MedTech Activity Diagram: Partitions Dr. Lilia SFAXI Slide 75 UML Design: Activity View • Partitions are used to organize the activities in a model according to responsibility • Activities are organized into distinct regions (partitions or swimlanes) separated by lines
  76. 76. MedTech Activity View: Control Flow • Activity Diagrams use: • Actions ( ) : for each major task performed by a user and/or the system • Connectors ( ): link the actions in sequence • Decision nodes ( ): indicate a point where the outcome of a decision dictates the next step • Guards ( ): indicate when each path should be taken • Merge Nodes ( ): bring together two or more alternative flows that branched at a Decision Node Dr. Lilia SFAXI Slide 76 UML Design: Activity View 1 2 3 4 5
  77. 77. MedTech Activity View: Data Flow • You can describe the data passing in and out of an activity in either of two ways: • Use an Object Node. : • Like a variable in a program. • Represents something that stores one or more values that are passing from one action to another. Dr. Lilia SFAXI Slide 77 UML Design: Activity View
  78. 78. MedTech Activity View: Data Flow • You can describe the data passing in and out of an activity in either of two ways: • Use an Output Pin and an Input Pin • Pins are like parameters in a program. • Pins represent ports where objects can enter and leave an action. Dr. Lilia SFAXI Slide 78 UML Design: Activity View
  79. 79. MedTech Activity View: Sub-Activities • Describe the detailed behavior of an action using a separate activity diagram. • A called behavior is an activity diagram that is represented on your main activity diagram by a Call Behavior Action. • Also used to describe behavior that is shared between different activities so that you do not have to draw the sub- activity multiple times. Dr. Lilia SFAXI Slide 79 UML Design: Activity View
  80. 80. MedTech Activity View: Concurrent Flows • You can use the Fork Node ( ) and the Join Node ( ) to describe two or more threads of activities that can execute at the same time. Dr. Lilia SFAXI Slide 80 UML Design: Activity View 1 2
  81. 81. MedTech Activity View: Concurrent Flows • Send Signal Action ( ): indicates that a signal or message is sent to other activities or processes. Dr. Lilia SFAXI Slide 81 UML Design: Activity View 3 4 • Accept Event Action ( ): indicates that this activity waits for some external event or incoming message.
  82. 82. MedTech Activity View: Case Study • Activity is started by a Commuter who needs to buy a ticket. • Ticket vending machine will request trip information from Commuter. This information will include number and type of tickets, e.g. whether it is a monthly pass, one way or round ticket, route number, destination or zone number, etc. • Based on the provided trip info ticket vending machine will calculate payment due and request payment options. Those options include payment by cash, or by credit or debit card. • If payment by card was selected by Commuter, another actor, Bank will participate in the activity by authorizing the payment. Dr. Lilia SFAXI Slide 82 UML Design: Activity View
  83. 83. MedTech Activity View: Proposition of a Solution Dr. Lilia SFAXI Slide 83 UML Design: Activity View
  84. 84. MedTech UML DESIGN: STATE MACHINE VIEW Design Dr. Lilia SFAXI Slide 84
  85. 85. MedTech State Machine View • State Machine • Models the possible life histories of an object of a class • Contains states connected by transitions • State • Models a period of time during the life of an object during which it satisfies certain conditions • Transition • Can be fired when an event occurs • Takes an object to a new state • When fired, it can execute an effect (action or activity) attached to it Dr. Lilia SFAXI Slide 85 UML Design: State Machine View
  86. 86. MedTech State Machine Diagram Dr. Lilia SFAXI Slide 86 UML Design: State Machine View State machine of a ticket to a performance
  87. 87. MedTech State Machine View : Transition • Indicates a movement from one state to another • Each transition has a label that comes in three parts (all optional): trigger-signature [guard]/activity • trigger-signature: Usually a single event that triggers a potential change of state • guard: Boolean condition that must be true for the transition to be taken • activity : Behavior executed during the transition Dr. Lilia SFAXI Slide 87 UML Design: State Machine View
  88. 88. MedTech State Machine View : Transition • Example of a seminar enrollment: trigger-signature [guard]/activity Dr. Lilia SFAXI Slide 88 UML Design: State Machine View
  89. 89. MedTech State Machine View : Internal Activities • States can react to events without transition, using internal activities • Putting the event, guard and activity inside the state box itself • Similar to a self-transition: transition that loops back to the same state Dr. Lilia SFAXI Slide 89 UML Design: State Machine View Internal activities for the state « Typing » of a text field
  90. 90. MedTech State Machine View : Activity States • In some states, the object can do some ongoing work • These are called Activity States Dr. Lilia SFAXI Slide 90 UML Design: State Machine View
  91. 91. MedTech State Machine View : Superstates • Several states can share common transitions and internal activities • Can be represented as substates, with the common behavior moved into a superstate Dr. Lilia SFAXI Slide 91 UML Design: State Machine View
  92. 92. MedTech State Machine View : Case Study • A student must complete the basic level before entering the advanced level • After both levels, the student has to pass five examinations • An examination can be retaken at most twice • After the third attempt, the student’s registration is cancelled Dr. Lilia SFAXI Slide 92 UML Design: State Machine View
  93. 93. MedTech State Machine View : Proposition of a (~) Solution Dr. Lilia SFAXI Slide 93 UML Design: State Machine View
  94. 94. MedTech UML DESIGN: OTHER VIEWS… Design Dr. Lilia SFAXI Slide 94
  95. 95. MedTech Deployment View • Represents the deployment of runtime artifacts on nodes • Artifact • Physical implementation unit (ex. a file) • Might be executable (.exe, binaries, jar…) or data files, configuration files, HTML documents... • Node • Runtime resource (ex. a computer, device or memory) • Listing an artifact into a node means that the artifact is deployed to that node Dr. Lilia SFAXI Slide 95 UML Design: Other Views
  96. 96. MedTech Deployment Diagram Dr. Lilia SFAXI Slide 96 UML Design: Other Views
  97. 97. MedTech Model Management View • Models the organization of the model itself • Comprises a set of packages that hold model elements, such as classes, state machines and use cases • Packages may contain other packages • Model management information is usually shown on package diagrams Dr. Lilia SFAXI Slide 97 UML Design: Other Views
  98. 98. MedTech Package Diagram Dr. Lilia SFAXI Slide 98 UML Design: Other Views
  99. 99. MedTech References Dr. Lilia SFAXI Slide 99 • Syed Muhammad Hammad-ud-Din, Software Design, 13430869 • Analysis and design of entreprise with uml, entreprise-with-uml • Microsoft Developer Network, Create UML modeling projects and diagrams, • Textbooks • J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual, Second Edition, Addison Wesley, 2004 • M. Fowler, UML Distilled, Third Edition, Addison-Wesley Professional, 2003

    Be the first to comment

    Login to see the comments

  • TusharPatil74

    Feb. 9, 2017
  • RenukaChahar

    Mar. 31, 2017
  • TayyabaAslam4

    Apr. 11, 2017
  • OleksandrVinnytskyi

    May. 15, 2018
  • vibhasharma27

    May. 21, 2018
  • CodyJustice

    Dec. 4, 2018
  • rahmaakaichi1

    Dec. 21, 2018
  • AhmedElnemr6

    Dec. 24, 2019
  • ManjuriyaV

    Mar. 17, 2020
  • ChinthakaBandara5

    Jul. 15, 2020
  • MeghaGaikwad12

    Sep. 28, 2020
  • MahammadSyed1

    Feb. 18, 2021
  • JaisuriyaY

    Apr. 21, 2021

Software Design


Total views


On Slideshare


From embeds


Number of embeds