1. CSC 506: Software Engineering and Knowledge Engineering
Dr. Syed Noman Hasany

2. Course Outline Review of known methodologies
Analysis of software requirements
Real-time software
Software cost, quality, testing and measurements
Object programming
Knowledge engineering issues: knowledge representation using rules, frames & logic, basics of logical inference, and basics of search.

3. Analysis of Software Requirements
Object Oriented: UML

4. System modeling using UML
System modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML).

5. What Is a Model?
Define what is meant by the term “model.”
A model is “a complete description of a system from a particular perspective.” A model is a simplification of reality.
According to Grady Booch, IBM Fellow, a model provides the blueprints of a system. Models may encompass detailed plans, as well as more general plans that give a 30,000-foot view of the system under construction. A good model includes those elements that are not relevant to the given level of abstraction. Every system may be described from different aspects using different models, and each model is therefore a semantically closed abstraction of the system. A model may be structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the dynamics of the system.
Copyright 2005 IBM Corp.

6. UML
The Unified Modeling Language is a set of 14 different diagram types that may be used to model software systems.
It emerged from work in the 1990s on object-oriented modeling where similar object-oriented notations were integrated to create the UML. A major revision (UML 2) was finalized in 2004.
The UML is universally accepted as the standard approach for developing models of software systems. Variants have been proposed for more general system modeling.

7. Why DFDs aren’t used in O-O
In DFDs a clear separation is made between processes and stored data.
It is assumed that all data is ‘visible’ to any process that needs to access it.
In an O-O system the processes that operate on data are the methods of the classes that contain the data as attributes.
Data is encapsulated within objects, and may be hidden too. 7

8. 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(collaboration)
Sequence
Interaction overview
Timing 8

9. UML diagrams
The UML has many diagram types and so supports the creation of many different types of system model. However, a survey in 2007 (Erickson and Siau, 2007) showed that most users of the UML thought that five diagram types could represent the essentials of a system:
Activity diagrams, which show the activities involved in a process or in data processing.
Use case diagrams, which show the interactions between a system and its environment.
Sequence diagrams, which show interactions between actors and the system and between system components.
Class diagrams, which show the object classes in the system and the associations between these classes.
State diagrams, which show how the system reacts to internal and external events.

10. UML diagrams
Fortunately, four UML diagramming techniques have come to dominate object-oriented projects:
Use case diagrams,
Class diagrams,
Sequence diagrams, and
Behavioral state machine diagrams.
The other diagramming techniques are useful for their particular purposes, but these four techniques form the core of UML as used in practice today

11. UML diagrams
The use case diagram is always created first, but the order in which the other diagrams are created depends upon the project and the personal preferences of the analysts.
Then class diagrams, sequence diagrams, and behavioral state machine diagrams are used to further define the evolving system from various perspectives.
Most analysts start either with the class diagrams (showing what objects contain and how they are related, much like ERDs) or the sequence diagrams (showing how objects dynamically interact, much like DFDs), but in practice, the process is iterative.
Developing sequence diagrams often leads to changes in the class diagrams and vice versa, so analysts often move back and forth between the two, refining each in turn as they define the system. Generally speaking, behavioral state machine diagrams are developed later, after the class diagrams have been refined.

12. UML diagrams Summary on diagrams discussion:
The use case is the foundation of UML, and its diagram contains the use cases.
A sequence diagram is created for every use case.
A class diagram is created for the system.
A state diagram is created for every complex class on the class diagram.

13. A. Context models
Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries.
System boundaries are established to define what is inside and what is outside the system.
They show other systems that are used or depend on the system being developed.

14. The context of the MHC-PMS

15. Process perspective
Simple context models are used along with other models, such as business process models. These describe human and automated processes in which particular software systems are used.
Process models reveal how the system being developed is used in broader business processes.
UML activity diagrams may be used to define business process models.

16. Process model of involuntary (spontaneous) detention

17. UML activity diagram Last figure is a UML activity diagram.
Activity diagrams are intended to show the activities that make up a system process and the flow of control from one activity to another.
The start of a process is indicated by a filled circle; the end by a filled circle inside another circle.
Rectangles with round corners represent activities, which are sub-processes that must be carried out.
A solid bar is used to indicate activity coordination.
When the flow from more than one activity leads to a solid bar then all of these activities must be complete before progress is possible.
When the flow from a solid bar leads to a number of activities, these may be executed in parallel.
Arrows may be annotated with guards that indicate the condition when that flow is taken.

18. Activity Diagram of a Library source: http://www.engr.sjsu.edu/~fayad
member
Librarian
[borrower]
Find book on shelf
[returning]
[returner]
Wait in queue
[borrowing]
Record return
Put book back of shelf
Record borrowing
Prepare for next
member 18

19. B. Interaction models
Modeling user interaction is important as it helps to identify user requirements.
Modeling system-to-system interaction highlights the communication problems that may arise.
Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability.
Use case diagrams and sequence diagrams may be used for interaction modeling.

20. Use case modeling
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.

21. Object-Oriented Analysis - Instructor Notes
Usages of a Use Case Model
Module 2 – Modeling System Behavior with Use Cases

22. Transfer-data use case
A use case in the MHC-PMS

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

24. Use cases in the MHC-PMS involving the role ‘Medical Receptionist’

25. Creating a Use Case Diagram
Identify Use Cases
Draw the System Boundary
Place the Use Cases on the Diagram
Identify the Actors
Add Association Relationships

26. Tune Source Digital Music Download System Use Case Diagram

27. Use Case Relationships
Represent communication between actor and use case
Depicted by line or double-headed arrow line
Also called association relationship
Other Types of Relationships for Use Cases
Generalization (From child to parent)
Include
Extend

28. Use Case Relationships

29. Use Case Relationships
Include Relationship
Represents the inclusion of the functionality of one use case within another
Common use case included in other use cases (avoids duplicate functionality)
Arrow is drawn from the base use case to the used use case
Write << include >> above arrowhead line
Include = reuse of functionality

30. Use Case Relationships
Extend relationship
Represents the extension of the use case to include optional functionality
Arrow is drawn from the extension use case to the base use case
Write << extend >> above arrowhead line
Extends = new and/or optional functionality
For example “assess fee” for ATM user drawing money from X-banks’ ATM where he does not have the account!

31. Use Case Relationships
Pro:
Reduces redundancy in use cases
Reduces complexity within a use case
Con
May introduce complexity to use case diagram

32. Assignment 3d (from ref. book)
Create a use case diagram for the system:
Owners of apartments fill in information forms about the rental units they have available (e.g., location, number of bedrooms, monthly rent), which are entered into a database. Students can search through this database via the Web to find apartments that meet their needs (e.g., a two-bedroom apartment for $800 or less per month within 1/2 mile of campus). They then contact the apartment owners directly to see the apartment and possibly rent it. Apartment owners call the service to delete their listing when they have rented their apartment(s).

33. Sequence diagrams
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.

35. Elements of a Sequence Diagram
Actors and objects participating in the sequence are placed across the top of the diagram, depicted by actor symbols from the use case diagram or unlabeled rectangles.
For each of the objects, the name of the class that they are an instance of is given after the object’s name.
A dotted line runs vertically below each actor and object to denote the lifeline of the actors/objects over time.

36. Elements of a Sequence Diagram
A thin, rectangular box, called the execution occurrence, is overlaid onto the lifeline to show when the classes are sending and receiving messages.
A message is a communication between objects that conveys information, with the expectation that activity will ensue, and messages passed between objects are shown by solid lines connecting two objects, called links.
The arrow on the link shows which way the message is being passed, and any argument values for the message are placed in parentheses next to the message’s name. The order of messages goes from top to bottom, so messages located higher on the diagram represent messages that occur earlier in the sequence, versus the lower messages that occur later.

37. Elements of a Sequence Diagram
There are times that a message is sent only if a condition is met. In those cases, the condition is placed between a set of [], such as [Authorization Ok]
It is possible to explicitly show the return from a message, with a return link, a dashed message. However, adding return links tends to clutter the diagram. Therefore, unless the return links add a lot of information to the diagram, they should be omitted.
The interaction operator alt means that the combined fragment represents a choice or alternatives of behavior.

38. Sequence diagram for “View patient information”

39. Description of the sequence diagram
The medical receptionist triggers the ViewInfo method in an instance P of the PatientInfo object class, supplying the patient’s identifier, PID. P is a user interface object, which is displayed as a form showing patient information.
The instance P calls the database to return the information required, supplying the receptionist’s identifier to allow security checking.
The database checks with an authorization system that the user is authorized for this action.
If authorized, the patient information is returned and a form on the user’s screen is filled in. If authorization fails, then an errormessage is returned.

40. Sequence diagram for Transfer Data
Chapter 5 System modeling

41. Description of the sequence diagram
The receptionist logs on to the PRS.
There are two options available. These allow the direct transfer of updated patient information to the PRS and the transfer of summary health data from the MHC-PMS to the PRS.
In each case, the receptionist’s permissions are checked using the authorization system.
Personal information may be transferred directly from the user interface object to the PRS. Alternatively, a summary record may be created from the database and that record is then transferred.
On completion of the transfer, the PRS issues a status message and the user logs off.

42. Sequence Diagram for Purchase Tunes Scenario

43. Sequence Diagram for Purchase Tunes Scenario
The shopping cart for a Web commerce application is used for temporarily capturing line items for an order, but once the order is confirmed, the shopping cart is no longer needed. In this case, an X would be located at the point at which the shopping cart object is destroyed. When objects continue to exist in the system after they are used in the sequence diagram, the lifeline continues to the bottom of the diagram.

44. C. Structural models
Structural models display the organization of a system in terms of the components that make up that system and their relationships.
Structural models may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing.
You create structural models of a system when you are discussing and designing the system architecture.

45. Class diagrams
Class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes.
An object class can be thought of as a general definition of one kind of system object.
An association is a link between classes that indicates that there is some relationship between these classes.
When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc.

46. UML classes and association

47. Classes and associations in the MHC-PMS

48. The Consultation class

49. Generalization
Generalization is an everyday technique that we use to manage complexity.
Rather than learn the detailed characteristics of every entity that we experience, we place these entities in more general classes (animals, cars, houses, etc.) and learn the characteristics of these classes.
This allows us to infer that different members of these classes have some common characteristics e.g. squirrels and rats are rodents.

50. Generalization
In modeling systems, it is often useful to examine the classes in a system to see if there is scope for generalization. If changes are proposed, then you do not have to look at all classes in the system to see if they are affected by the change.
In object-oriented languages, such as Java, generalization is implemented using the class inheritance mechanisms built into the language.
The lower-level classes are subclasses inherit the attributes and operations from their superclasses. These lower-level classes then add more specific attributes and operations.

51. A generalization hierarchy

52. A generalization hierarchy with added detail

53. Object class aggregation models
An aggregation model shows how classes that are collections are composed of other classes.
Aggregation models are similar to the part-of relationship in semantic data models.

54. The aggregation association

55. D. Behavioral models
Behavioral models are models of the dynamic behavior of a system as it is executing.
Stimuli types and UML diagrams:
Data Some data arrives that has to be processed by the system.
Modeled by activity models
Events Some event happens that triggers system processing. Events may have associated data, although this is not always the case.
Modeled by state machine models

56. Data-driven modelling in UML
The UML does not support data-flow diagrams as they were originally proposed and used for modeling data processing. The reason for this is that DFDs focus on system functions and do not recognize system objects. However, because data-driven systems are so common in business, UML 2.0 introduced activity diagrams, which are similar to data-flow diagrams.
An alternative way of showing the sequence of processing in a system is to use UML sequence diagrams.

57. Data driven modelling in UML: activity model of the insulin pump’s operation

58. Data driven modelling in UML: sequence diagram for Order processing
**But note that, sequence models highlight objects in a system, whereas data-flow diagrams highlight the functions.

59. Event-driven modeling
Real-time systems are often event-driven, with minimal data processing. For example, a landline phone switching system responds to events such as ‘receiver off hook’ by generating a dial tone.
Event-driven modeling shows how a system responds to external and internal events.
It is based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another.

60. State machine models
Activity diagram is used to document the logic of a single operation/method, a single use case or the flow of logic of a business process. It is equivalent to flowchart and data flow diagram from structured development.
The state diagram depict (show) the state of objects as their attributes change from state to the other state. State chart modeling is used to show the sequence of states that an object goes through, the cause the transition from one state to other and the action that result from a state change.

61. State machine models
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.
State charts are an integral part of the UML and are used to represent state machine models.

63. State diagram of a microwave oven

64. States for the microwave oven example
Description
Waiting
The oven is waiting for input. The display shows the current time.
Half power
The oven power is set to 300 watts. The display shows ‘Half power’.
Full power
The oven power is set to 600 watts. The display shows ‘Full power’.
Set time
The cooking time is set to the user’s input value. The display shows the cooking time selected and is updated as the time is set.
Disabled
Oven operation is disabled for safety. Interior oven light is on. Display shows ‘Not ready’.
Enabled
Oven operation is enabled. Interior oven light is off. Display shows ‘Ready to cook’.
Operation
Oven in operation. Interior oven light is on. Display shows the timer countdown. On completion of cooking, the buzzer is sounded for five seconds. Oven light is on. Display shows ‘Cooking complete’ while buzzer is sounding.

65. Stimuli for the microwave oven example
Stimulus
Description
Half power
The user has pressed the half-power button.
Full power
The user has pressed the full-power button.
Timer
The user has pressed one of the timer buttons.
Number
The user has pressed a numeric key.
Door open
The oven door switch is not closed.
Door closed
The oven door switch is closed.
Start
The user has pressed the Start button.
Cancel
The user has pressed the Cancel button.

66. Activity Diagram of a Bank ATM

67. State Diagram of a Bank ATM
Customer Authentication and Transaction are composite states by themselves which is shown with hidden decomposition indicator icon.

68. Model-driven engineering
Model-driven engineering (MDE) is an approach to software development where models rather than programs are the principal outputs of the development process.
The programs that execute on a hardware/software platform are then generated automatically from the models.

69. Usage of model-driven engineering
Model-driven engineering is still at an early stage of development, and it is unclear whether or not it will have a significant effect on software engineering practice.
Pros
Allows systems to be considered at higher levels of abstraction
Generating code automatically means that it is cheaper to adapt systems to new platforms.
Cons
Models for abstraction and not necessarily right for implementation.
Savings from generating code may be outweighed by the costs of developing translators for new platforms.

70. Model driven architecture
Model-driven architecture (MDA) was the precursor of more general model-driven engineering
MDA is a model-focused approach to software design and implementation that uses a subset of UML models to describe a system.
Models at different levels of abstraction are created. From a high-level, platform independent model, it is possible, in principle, to generate a working program without manual intervention.

71. Types of model A computation independent model (CIM)
These model the important domain abstractions used in a system. CIMs are sometimes called domain models. It describes how a system should behave/represent in terms of a language that is appropriate for a user (e.g. an educational designer, a business analyst, etc.)
A platform independent model (PIM)
These model the operation of the system without reference to its implementation. The PIM is usually described using UML models that show the static system structure and how it responds to external and internal events.

72. Types of model Platform specific models (PSM)
These are transformations of the platform-independent model with a separate PSM for each application platform. In principle, there may be layers of PSM, with each layer adding some platform-specific detail.

73. MDA discussion
Automatic CIM to PIM translation is still at the research prototype stage. It is unlikely that completely automated translation tools will be available in the near future.

74. MDA transformations

75. Multiple platform-specific models

76. Executable UML
The fundamental notion behind model-driven engineering is that completely automated transformation of models to code should be possible.
This is possible using a subset of UML 2, called Executable UML or xUML.

77. Model-driven Software Development
Reality: A stock exchange lists many companies. Each company is identified by a ticker symbol
Analysis results in analysis object model (UML Class Diagram): * *
StockExchange
Company
Lists
tickerSymbol
Implementation results in source code (Java):
public class StockExchange {
public m_Company = new Vector(); };
public class Company {
public int m_tickerSymbol;
public Vector m_StockExchange = new Vector();

78. Features of executable UML
To create an executable subset of UML, the number of model types has therefore been dramatically reduced to these 3 key types:
Domain models that identify the principal concerns in a system. They are defined using UML class diagrams and include objects, attributes and associations.
Class models in which classes are defined, along with their attributes and operations.
State models in which a state diagram is associated with each class and is used to describe the life cycle of the class.
The dynamic behavior of the system may be specified declaratively using the object constraint language (OCL), or may be expressed using UML’s action language.

79. Key points
A model is an abstract view of a system that ignores system details. Complementary system models can be developed to show the system’s context, interactions, structure and behaviour.
Context models show how a system that is being modeled is positioned in an environment with other systems and processes.
Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the system being designed. Use cases describe interactions between a system and external actors; sequence diagrams add more information to these by showing interactions between system objects.
Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system and their associations.

80. Key points
Behavioral models are used to describe the dynamic behavior of an executing system. This behavior can be modeled from the perspective of the data processed by the system, or by the events that stimulate responses from a system.
Activity diagrams may be used to model the processing of data, where each activity represents one process step.
State diagrams are used to model a system’s behavior in response to internal or external events.
Model-driven engineering is an approach to software development in which a system is represented as a set of models that can be automatically transformed to executable code.