Software Engineering Software Design Models UML Where

Software Engineering Software Design Models UML

Where are we? Phase Actions Outcome Initiation Raising a business need Business documents Requirements Interviewing stakeholders, exploring the system environment Organized documentation Specification Analyze the engineering aspect of the system, building system concepts Formal specification Design Define architecture, components, data types, algorithms Formal Specification Implementation documentation Program, build, unit-testing, integrate, Testable system Testing & Integration Integrate all components, verification, validation, installation, guidance Testing results, Working sys Maintenance Bug fixes, modifications, adaptation System versions

Requirements vs. Design l Requirements: • • l What the system should do More abstract Design: • • How the system should do it More detailed

Object Oriented Modeling

The Unified Modelling Language l The Unified Modelling Language is a standard graphical language for modelling object oriented software • At the end of the 1980 s and the beginning of 1990 s, the first object-oriented development processes appeared • In 1995, another methodologist, Jacobson, joined the team » His work focused on use cases • In 1997 the Object Management Group (OMG) started the process of UML standardization 5

History of UML

Overview of UML Diagrams Structural Behavioral : behavioral features of a system / business process : element of spec. irrespective of time l Activity State machine Use case l Interaction l l l l Class Component Deployment Object Composite structure Package l Interaction : emphasize object interaction • Communication(collaberati on) • Sequence • Interaction overview • Timing

13 (!!) Kinds of UML Diagrams 1) 2) 3) 4) 5) 6) 7) Activity Class Communication Component structure Deployment Interaction 8) 9) 10) 11) 12) 13) Object Package Sequence State machine Timing Use case

Models and Diagrams Use Case Diagrams Sequence Diagrams Scenario Diagrams Collaboration Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams State Diagrams Class Diagrams Models State Diagrams Object Diagrams State Diagrams Component Diagrams Deployment Diagrams Activity Diagrams

Diagrams in UML A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships). • Class diagram shows a set of classes, interfaces, and collaborations with their relationships. • Object diagram shows a set of objects and their relationships. • Use case diagram shows a set of use cases and actors (a special kind of class) and their relationships.

Diagrams in UML (continued) • Interaction diagram shows an interaction, consisting of a set of objects and the relationships, including the messages that may be dispatched among them. => A sequence diagram emphasizes the time ordering. => A collaboration diagram emphasizes the structural organization of the objects that send and receive messages.

Diagrams in UML (continued) • Statechart diagram shows a state machine consisting of states, transitions, events, and activities. • Activity diagram is a statechart diagram that shows the flow from activity to activity within a system. • Component diagram shows the organization and dependencies among a set of components. • Deployment diagram shows the configuration of processing nodes and the components that live on them.

Class Diagrams

UML Class Diagrams l The main symbols shown on class diagrams are: • • • Classes represent the types of data themselves Associations represent linkages between instances of classes Attributes are simple data found in classes and their instances Operations represent the functions performed by the classes and their instances Generalizations group classes into inheritance hierarchies 14

Notation: Classes Window name origin size attributes open() close() move() display() operations A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.

Class Name Attribute : type Operation (arg list) : return type Abstract operation Various parts are optional

Classes l A class is simply represented as a box with the name of the class inside • • The diagram may also show the attributes and operations The complete signature of an operation is: operation. Name(parameter. Name: parameter. Type …): return. Type 17

Employee class (UML)

Example UML Class Diagram

Kinds of Edges Association Class A Navigability Source Role of B Role of A Role name Class B Target Dependency Client Supplier There are other kinds of edges

Multiplicities on Edges (Cardinalities) 1 * 0. . 1 m. . n {ordered}* Exactly one Many (any number) Optional (zero or one) Specified range Ordered

Multiplicity of associations n one-to-one n n each student must carry exactly one ID card one-to-many n one rectangle list can contain many rectangles 22

Car Association types l aggregation: "is part of" • l symbolized by a clear white diamond aggregation Engine composition: "is entirely made of" • • • l 1 1 stronger version of aggregation the parts live and die with the whole symbolized by a black diamond Book composition 1 * dependency: "uses temporarily" • • symbolized by dotted line often is an implementation detail, not an intrinsic part of that object's state Page dependency Lottery Ticket Random 23

Composition • A composition is a strong kind of aggregation » if the aggregate is destroyed, then the parts are destroyed as well Building * Room • Two alternatives for addresses

An association model

Labelling associations • Each association can be labelled, to make explicit the nature of the association

Analyzing and validating associations • One-to-one » For each company, there is exactly one board of directors » A board is the board of only one company » A company must always have a board » A board must always be of some company

Analyzing and validating associations • Many-to-many » A secretary can work for many managers » A manager can have many secretaries » Secretaries can work in pools » Managers can have a group of secretaries » Some managers might have zero secretaries. » Is it possible for a secretary to have, perhaps temporarily, zero managers?

A more complex example • A booking is always for exactly one passenger » no booking with zero passengers » a booking could never involve more than one passenger. • A Passenger can have any number of Bookings » a passenger could have no bookings at all » a passenger could have more than one booking

Class diagram example Student. Body + main (args : String[]) Address 1 100 Student - first. Name : String - last. Name : String - home. Address : Address - school. Address : Address + to. String() : String - street. Address : String - city : String - state : String - zip. Code : long + to. String() : String 31

Reflexive associations • It is possible for an association to connect a class to itself successor * Course * * is. Mutually. Exclusive. With * prerequisite 32

Detailed Example: A Class Diagram for Genealogy • Problems » A person must have two parents » Marriages not properly accounted for

Genealogy example: Possible solutions Person name sex place. Of. Birth date. Of. Birth place. Of. Death child date. Of. Death * partner 0. . 2 * {partner->for. All(p 1, p 2 | p 1 <> p 2 implies p 1. sex <> p 2. sex)} * Union name place. Of. Birth date. Of. Birth place. Of. Death child date. Of. Death * Woman 0. . 1 place. Of. Marriage parents date. Of. Marriage date. Of. Divorce Man female. Partner 0. . 1 * 0. . 1 male. Partner child * * Union 0. . 1 place. Of. Marriage parents date. Of. Marriage date. Of. Divorce 34

Note (Comment) Comment about an item Some item eg class

Generalization (Inheritance) Supertype Subtype 1 Subtype 2

Generalisation and inheritance l l Objects are members of classes which define attribute types and operations Classes may be arranged in a class hierarchy where one class (a super-class) is a generalisation of one or more other classes (sub-classes) A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own Generalisation in the UML is implemented as inheritance in OO programming languages

Generalization l Specializing a superclass into two or more subclasses • The discriminator is a label that describes the criteria used in the specialization 39

A generalisation hierarchy

Multiple inheritance

Class diagram example Multiplicity Customer Class Simple 1 Aggregation Rental Invoice Abstract Class Rental Item 1. . * 1 0. . 1 Composition Simple Generalization DVD Movie Association VHS Movie Video Game Checkout Screen 43

An example (generalization) Person. Role 0. . 2 Person name id. Number Employee. Role Passenger. Role job. Function Regular. Flight * supervisor time flight. Number * * Booking seat. Number * * * Specific. Flight date 44

Class attributes l attributes (fields, instance variables) • • • visibility name : type [count] = default_value visibility: + public # protected - private ~ package (default) / derived underline static attributes derived attribute: not stored, but can be computed from other attribute values attribute example: - balance : double = 0. 00 45

Association classes • Sometimes, an attribute that concerns two associated classes cannot be placed in either of the classes • The following are equivalent * Student * Course. Section Registration grade Student * Registration * grade Course. Section

An example (attributes and associations) Employee Passenger name employee. Number job. Function name number Regular. Flight * supervisor * * Booking seat. Number * * * Specific. Flight date time flight. Number

Instance Specification (Object) Object. Name: Class Name Attribute : type Operation (arg list) : return type Abstract operation Various parts are optional

Object diagram

Object Diagram Track Instance Behavior l l Class Diagram Instance Diagram

Object aggregation

Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules.

Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules.

Candidate Classes Library Book Journal Copy Short. Term. Loan Library. Member Week Member. Of. Library Item Time Member. Of. Staff System Rule the name of the system event measure repeat book or journal abstract term general term

Relations between Classes Book Journal Copy Library. Member Item Member. Of. Staff Is Item needed? is an is a copy of a Item Book is a Library. Member

Operations Library. Member borrows Copy Library. Member returns Copy Member. Of. Staff borrows Journal Member. Of. Staff returns Journal Item not needed yet.

Class Diagram Member. Of. Staff Library. Member 1 1 on loan 0. . 12 Journal 0. . * Copy is a copy of Book 1. . * 1

Representing Architecture: The 4+1 View Model Logical View Analysts/ Designers Structure End-user Functionality Process View System Integrators Performance Scalability Throughput Implementation View Use-Case View Programmers Software management Deployment View System Engineering System topology Delivery, installation communication

Major Workflows Produce Models Business Modeling supported by Business Model Requirements Analysis & Design realized by Use-Case Model implemented by Design Model verified by Implementation Model Test Model 63

Software Engineering Software Design Models UML

Overview of UML Diagrams Structural Behavioral : behavioral features of a system / business process : element of spec. irrespective of time l Activity State machine Use case l Interaction l l l l Class Component Deployment Object Composite structure Package l Interaction : emphasize object interaction • Communication(collaberati on) • Sequence • Interaction overview • Timing

Use Case Diagram l l l Used for describing a set of user scenarios Mainly used for capturing user requirements Work like a contract between end user and software developers

Use case modeling l l Use cases were developed originally to support requirements elicitation and now incorporated into the UML. Each use case represents a discrete task that involves external interaction with a system. Actors in a use case may be people or other systems. Represented diagramatically to provide an overview of the use case and in a more detailed textual form.

Use cases diagram UML 2 Use cases diagrams l Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse. l Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures. l Associations between actors and use cases are indicated by solid lines. An association exists whenever an actor is involved with an interaction described by a use case.

Use Case Diagram (core components) Actors: A role that a user plays with respect to the system, including human users and other systems. e. g. , inanimate physical objects (e. g. robot); an external system that needs some information from the current system. Use case: A set of scenarios that describing an interaction between a user and a system, including alternatives. System boundary: rectangle diagram representing the boundary between the actors and the system.

Use Case Diagram(core relationship) Association: communication between an actor and a use case; Represented by a solid line. Generalization: relationship between one general use case and a special use case (used for defining special alternatives) Represented by a line with a triangular arrow head toward the parent use case.

Use-Case Diagram A use case diagram is a collection of actors, use cases, and their communications.

Use cases diagram

Use Case (Cont’d) Here we have a Student interacting with the Registrar and the Billing System via a “Register for Courses” use case. Billing System Student Register for Courses Registrar

Example of Use Case Diagram registration student updating grades output generating faculty

Transfer-data use case l A use case in the MHC-PMS

Use-Case Diagram A use case diagram is a collection of actors, use cases, and their communications.

Example of Relationships

Example Use-case Diagram for a student database

Example use case diagram 3 Customer Applicant Order Food Service Person Hire Employee Reorder supplies <> Supplier Manager <> Track sales and inv. data Produce mgt. reports 79

Example use case diagram Control System Scan Set limits Experimental Physicist Liason Physicist Take profile Calibrate Hardware Specialist 80

Example use case diagram 81

involving the role ‘Medical Receptionist’

Tabular description of the ‘Transfer data’ use-case MHC-PMS: Transfer data Actors Medical receptionist, patient records system (PRS) Description A receptionist may transfer data from the MHC-PMS to a general patient record database that is maintained by a health authority. The information transferred may either be updated personal information (address, phone number, etc. ) or a summary of the patient’s diagnosis and treatment. Data Patient’s personal information, treatment summary Stimulus User command issued by medical receptionist Response Confirmation that PRS has been updated Comments The receptionist must have appropriate security permissions to access the patient information and the PRS.

Use case tables l formal use cases can also be written as a table: 84

One method to do use cases Now that we know the syntax for doing use cases, what 4 steps does Cockburn recommend when actually brainstorming and writing our use cases? 1. identify actors and their goals 2. write the main success scenario 3. identify and list possible failure extensions 4. describe how the system handles each failure Let's look at each step in detail. . . 85

Use cases diagram

Use Case Diagram - University System URS add member system user del member add subject academic del subject assg subject unass subject enrol subject student unenrol subject

Use Case Diagram for Student Assessment Management System Grade system Record grades Student View grades Teacher Distribute Report cards Create report cards Printing administrator

Example: video store system Actor: Customer - What tasks does the actor want the system to perform? - Find movie to rent, rent tape, return tape, reserve tape - What information must the actor provide to the system? - Name, address, membership#, film name - Are there events that the actor must tell system about? - Change of address - Does actor need to be informed when something happens? - Reserved tape is ready to be rented - Does actor help initialize or shut down the system - no

Example: video store system Resulting use cases: » Customer joins and provides contact information including name, address, phone#, credit information, spouse and kids » Customer browses system looking for a tape to rent » Customer comes to store looking for a specific tape to rent » Customer rents a tape » Customer returns a tape » Customer reserves a tape » Customer is contacted when a reserved tape is ready Note: simple phrases, without much details initially.

©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 7 Slide 91

Example use case Use Case. Buy stocks over the web Primary Actor: Purchaser (user) Scope: PAF Level: user goal Precondition: User already has PAF open. Guarantees: sufficient log information exists that PAF can detect what went wrong. Success Guarantees: remote web site acknowledged purchase, user's portfolio updated. Main success scenario: 1. User selects to buy stocks over the web. 2. PAF gets name of web site to use (E*Trade, Schwabb, etc. ) 3. PAF opens web connection to the site, retaining control. 4. User browses and buys stock from the web site. 5. PAF intercepts responses from the web site, and updates the user's portfolio. 6. PAF shows the user the new portfolio standing. Extensions: 2 a. User wants a web site PAF does not support: 2 a 1. System gets new suggestion from user, with option to cancel use case. 3 a. .

Example l l l International Alexandria University wants to install a new student self-service system for student enrollment, registration and payment. A local bank called YMOM (Your Money is Our Money) Bank Corp. will join Alexandria to create a flexible bank account that can be used to conveniently pay for courses as well as other oncampus expenses. Alexandria will issue a new campus-wide Id card that combines all the features of a bank ATM card as well as a University ID card.

The course registration system is available as a webbased application. It is part of the joint application maintained by ALEXU and YMOM. The following are some of the business rules: l Every course has a cost. l Every course has an optional list of prerequisites, in the form a list of courses. l A student must have an established Alexu student enrollment record in the system, with an ID card and YMOM account before registering for a course. l A student will have a list of courses, described with the quarter they took the course, payment status and their grade, if appropriate. l

l l l l A student can register for a course without having the money to pay for it in their YMOM account, as long as all prior courses have been paid for. Registration for a specific course is only possible during a defined window of time, 3 week before the end of the current quarter and 2 weeks into the beginning of the next quarter. A student will not see a grade for a course unless they have registered for the course and have paid for it in full. A professor can submit a grade for a course for a student. A student may declare a Major and a Minor, each one implying a list of required and optional courses. A student can drop a course they have registered for and the money will be automatically made available in their YMOM account. The students can access the system via their own PC accessing the web or via a network of YMOM ATMs

l l l The number on their student id/ATM card is the user id for the application and the ATM PIN number is the password for the site. They can: 1. See their current transcripts, 2. Register for a course in the next quarter. When they register for a course, they will be presented with the set of courses that match their Major or Minor selections, the current courses offered and the courses with which they have fulfilled the prerequisites. 3. Transfer funds from the YMOM account to pay for a course.

l l The University is a progressive IT customer. They want to roll out system functionality as fast as it can be made available. They want to engage student-lead focus groups to assess the quality and acceptance of the application. They are concerned with the security and integration of the application with the YMOM systems. The system development is not with out risks however, as CS 305 has very limited experience with the kind of networking complexity and

Sequence Diagrams

Sequence diagrams l l Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system. A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance. The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. Interactions between objects are indicated by annotated arrows.

Sequence diagram for View patient information

Sequence diagram for Transfer Data

Classes and associations in the MHC-PMS

A generalization hierarchy

A generalization hierarchy with added detail

Example for Sequence Diagram [Fowler] l 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.

Example for Sequence Diagram [Fowler] l 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.

Example Sequence Diagram an. Order calculate. Price Found message an. Order. Line a. Customer a. Product get. Quantity get. Product Participant Lifeline a. Product Activation get. Pricing. Details get. Base. Price Return Self call Message calculate. Discounts get. Discount. Info

Elements of Sequence Diagrams Name: Class Create New object Message Self-call Return Delete There is also notation for loops, conditions, etc.

State machine models l l These model the behaviour of the system in response to external and internal events. They show the system’s responses to stimuli so are often used for modelling real-time systems. State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another. Statecharts are an integral part of the UML and are used to represent state machine models.

State diagram of a microwave oven

Weather system description A weather data collection system is required to generate weather maps on a regular basis using data collected from remote, unattended weather stations and other data sources such as weather observers, balloons and satellites. Weather stations transmit their data to the area computer in response to a request from that machine. The area computer validates the collected data and integrates it with the data from different sources. The integrated data is archived and, using data from this archive and a digitised map database a set of local weather maps is created. Maps may be printed for distribution on a specialpurpose map printer or may be displayed in a number of different formats.

Weather station description A weather station is a package of software controlled instruments which collects data, performs some data processing and transmits this data for further processing. The instruments include air and ground thermometers, an anemometer, a wind vane, a barometer and a rain gauge. Data is collected every five minutes. When a command is issued to transmit the weather data, the weather station processes and summarises the collected data. The summarised data is transmitted to the mapping computer when a request is received.

Subsystems in the weather mapping system

Use-cases for the weather station

Use-case description

Weather station object classes l Ground thermometer, Anemometer, Barometer • l Weather station • l Application domain objects that are ‘hardware’ objects related to the instruments in the system The basic interface of the weather station to its environment. It therefore reflects the interactions identified in the use-case model Weather data • Encapsulates the summarised data from the instruments

Weather station object classes

Weather station subsystems

Sequence models l Sequence models show the sequence of object interactions that take place • • Objects are arranged horizontally across the top Time is represented vertically so models are read top to bottom Interactions are represented by labelled arrows, Different styles of arrow represent different types of interaction A thin rectangle in an object lifeline represents the time when the object is the controlling object in the system

Data collection sequence

Statecharts l Show objects respond to different service requests and the state transitions triggered by these requests • • • If object state is Shutdown then it responds to a Startup() message In the waiting state the object is waiting for further messages If report. Weather () then system moves to summarising state If calibrate () the system moves to a calibrating state A collecting state is entered when a clock signal is received

State Diagram returned() not borrowable returned() borrowable borrowed()[last copy] guard expression borrowed()[not last copy] State diagram for class Book

Weather station state diagram