Software Design Models UML Software Engineering Software Design Models UML

Where are we? Phase Actions Outcome Initiation Requirements 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 Program, build, unit-testing, integrate, documentation 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 What the system should do More abstract Design: How the system should do it More detailed

Object Oriented Modeling Evolution of analysis and design techniques Transition from structured programming to object oriented programming

The Unified Modelling Language The Unified Modelling Language is a standard graphical language for modelling object oriented software At the end of the 1980s and the beginning of 1990s, 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

History of UML

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

13 (!!) Kinds of UML Diagrams Activity Class Communication Component Component structure Deployment Interaction Object Package Sequence State machine Timing Use case

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 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

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

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

Classes 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: operationName(parameterName: parameterType …): returnType

Employee class (UML)

Example UML Class Diagram

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

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

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

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

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

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 StudentBody Student Address 1 100 - firstName : String - lastName : String - homeAddress : Address - schoolAddress : Address + main (args : String[]) + toString() : String Address - streetAddress : String - city : String - state : String - zipCode : long + toString() : String

Reflexive associations It is possible for an association to connect a class to itself successor * Course isMutuallyExclusiveWith * * * prerequisite

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

Genealogy example: Possible solutions Person Person name name sex placeOfBirth placeOfBirth dateOfBirth dateOfBirth placeOfDeath child placeOfDeath child dateOfDeath * dateOfDeath * {partner->forAll(p1,p2 | partner * * * * 0..2 p1 <> p2 implies p1.sex <> p2.sex)} * Woman Man Union femalePartner child 0..1 * * * * 0..1 child malePartner 0..1 placeOfMarriage parents * * dateOfMarriage dateOfDivorce Union 0..1 placeOfMarriage parents dateOfMarriage dateOfDivorce

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

Generalization (Inheritance) Supertype Subtype 1 Subtype 2

Generalisation and inheritance 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 Specializing a superclass into two or more subclasses The discriminator is a label that describes the criteria used in the specialization

A generalisation hierarchy

Multiple inheritance

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

An example (generalization) Person 0..2 0..2 0..2 0..2 0..2 0..2 PersonRole name idNumber RegularFlight * EmployeeRole time PassengerRole flightNumber jobFunction supervisor * * * * * * * * * * * * * * * * * * * Booking * * * * * * SpecificFlight seatNumber date

Class attributes 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

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

An example (attributes and associations) Employee RegularFlight Passenger name * name time employeeNumber number flightNumber jobFunction supervisor * * * * * * * * * * * * * * * * * * * Booking * * * * * * SpecificFlight seatNumber date

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

Object 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 the name of the system Book Journal Copy ShortTermLoan event LibraryMember Week measure MemberOfLibrary repeat Item book or journal Time abstract term MemberOfStaff System general term Rule general term

Relations between Classes Book is an Item Journal is an Item Copy is a copy of a Book LibraryMember Item MemberOfStaff is a LibraryMember Is Item needed?

Operations LibraryMember borrows Copy LibraryMember returns Copy MemberOfStaff borrows Journal MemberOfStaff returns Journal Item not needed yet.

Class Diagram MemberOfStaff LibraryMember 1 1 on loan on loan 0..* 0..12 Journal Copy is a copy of 1..* 1 Book

Representing Architecture: The 4+1 View Model It is important to keep the discussion of this slide at a very high level. Examples of the 5 views are not provided. You may wish to go to the white board and show some examples. Several examples from earlier in this module can be used. For example, The sample use case diagram can illustrate the use-case view. The sample class diagram can illustrate the logical view. Also mention that the UML provides the notation we use to visualize these views. Logical View Implementation View Analysts/ Designers End-user Programmers Software management Structure Functionality Use-Case View Many different parties are interested in the architecture (e.g., the system analyst, the designers, the end uses, etc.). To allow these parties or stakeholders to communicate, discuss and reason about architecture, we need to have an architectural representation that they understand. Because different stakeholders have different concerns and because architecture is quite complex, multiple views are required to represent architecture adequately. An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns,and omitting entities that are not relevant to this perspective. While many views of architecture can be useful, the Rational Unified Process identifies 4+1 views as a standard set: The logical view addresses the functional requirements of the system. It is an abstraction of the design model, identifying major design packages, subsystems and classes. The implementation view describes the organization of static software modules in the development environment, in terms of packaging, layering, and configuration management. The process view addresses the concurrent aspect of the system at run-time: tasks, threads or processes, and their interactions. The deployment view shows how the various executables and other run-time components are mapped onto the underlying platforms or computing nodes. The use-case view contains a few key scenarios or use cases that are used to drive the architecture and to validate it. Process View Deployment View System Integrators System Engineering Performance Scalability Throughput System topology Delivery, installation communication

Major Workflows Produce Models You can relate this back to previous slides that describe the system model and the many diagrams needed to fully communicate its content. One can consider all of the models listed here, taken together, to be “the system model.” The only model that is a little different is the business model. It describes the business at large, not just the automated part. The other models describe the information system that supports the business model. It is a good idea to point out that each of these models is incrementally developed across many iterations. Analysis & Design Design Model Implementation Model Test Model realized by implemented by verified by Requirements Implementation Test Use-Case Model Business Modeling Business Model supported by The Rational Unified Process is a model-driven approach. Several models are needed to fully describe the evolving system. Each major workflow produces one of those models. The models are developed incrementally across iterations. The Business Model is a model of what the business processes are and the business environment. It can be used to generate requirements on supporting information systems. The Use-Case Model is a model of what the system is supposed to do and the system environment. The Design Model is an object model describing the realization of use cases. It serves as an abstraction of the implementation model and its source code. The Implementation Model is a collection of components, and the implementation subsystems that contain them. The Test Model encompasses all of the test cases and procedures required to test the system.