Winter 2007, rev. 2008SEG2101 - Chapter 21 Chapter 2 Basic Principles.

Slides:



Advertisements
Similar presentations
Introduction to Object Orientation System Analysis and Design
Advertisements

© Alan Burns and Andy Wellings, 2001 Real-Time Systems and Programming Languages n Buy Real-Time Systems: Ada 95, Real-Time Java and Real-Time POSIX by.
Modeling Main issues: What do we want to build How do we write this down.
Modeling Main issues: What do we want to build How do we write this down ©2008 John Wiley & Sons Ltd. vliet.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Object-Oriented Analysis and Design
Winter 2007SEG2101 Chapter 41 Chapter 4 SDL – Structure and Behavior.
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Introduction To System Analysis and Design
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 8 The Enhanced Entity- Relationship (EER) Model.
Real-Time Systems and Programming Languages
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
© Copyright Eliyahu Brutman Programming Techniques Course.
Ch5: Software Specification. 1 Overview  Use of specifications  Specification qualities  Classification of specification styles  Verification of specifications.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Winter 2012SEG Chapter 11 Chapter 1 (Part 2) Introduction to Requirements Modeling.
UML Sequence Diagrams Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
Chapter 7: The Object-Oriented Approach to Requirements
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Introduction To System Analysis and design
OO Analysis and Design CMPS OOA/OOD Cursory explanation of OOP emphasizes ▫ Syntax  classes, inheritance, message passing, virtual, static Most.
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 4 - System modelling Dr Richard Clayton.
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 12 Object-Oriented.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Introduction To System Analysis and Design
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
EEL Software development for real-time engineering systems.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Conceptual Modelling – Behaviour
1 Devon M. Simmonds University of North Carolina, Wilmington CSC450 Software Engineering WorkFlow Modeling with Activity Diagrams.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
The Static Analysis Model Class Diagrams Prof. Hany H. Ammar, CSEE, WVU, and Dept. of Computer Science, Faculty of Computers and Information, Cairo University.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
Design Model Lecture p6 T120B pavasario sem.
OMT Modeling 1. Object Model : presented by the object model and the data dictionary. 2. Dynamic Model: presented by the state diagrams and event flow.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
UML / UML 2.0 Diagrams (Part I) 1. Overview of the 13 diagrams of UML Structure diagrams 1.Class diagram 2.Composite structure diagram (*) 3.Component.
1 Software Design Lecture What’s Design It’s a representation of something that is to be built. i.e. design  implementation.
22 August, 2007Information System Design IT60105, Autumn 2007 Information System Design IT60105 Lecture 8 Use Case Diagrams.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Winter 2007SEG2101 Chapter 31 Chapter 3 Requirements Specifications.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Object-Oriented Software Engineering Practical Software Development using UML and Java Modelling with Classes.
Communication Diagrams Lecture 8. Introduction  Interaction Diagrams are used to model system dynamics  How do objects change state?  How do objects.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
Diagrams. Typically, we view the static parts of a system using one of the four following diagrams. 1. Class diagram 2. Object diagram 3. Component diagram.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
From requirements to specification Specification is a refinement of requirements Can be included together as Software Requirements Specifications (SRS)
Systems Analysis and Design in a Changing World, Fourth Edition
UML Diagrams: Class Diagrams The Static Analysis Model
The Movement To Objects
Main issues: • What do we want to build • How do we write this down
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
Unified Modeling Language
Comparison between UML Activity Diagrams and Use Case Maps
University of Houston-Clear Lake
Chapter 20 Object-Oriented Analysis and Design
Dynamic Modeling Lecture # 37.
Introduction to Requirements Modeling
Comparison between UML Activity Diagrams and Use Case Maps
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Software Development Process Using UML Recap
Presentation transcript:

Winter 2007, rev. 2008SEG Chapter 21 Chapter 2 Basic Principles

Winter 2007, rev. 2008SEG Chapter 22 Basic Principles Introduction to the system example Systems Techniques to manage complexity Approaches to behavior description Some description approaches The methodology presented here The SOON notation

Winter 2007, rev. 2008SEG Chapter : Introduction to the System Example Access Control System (AC-System) Access point: controlled by local station, physically distributed to where the services are needed Local station: control unit, a door lock mechanism, one or two panels, each contains a card reader, a display unit, and a keypad Central station: keeps information about the users, their access rights, their cards, and their secret PINs, performs authentication and authorization.

Winter 2007, rev. 2008SEG Chapter 24 Panel and Card

Winter 2007, rev. 2008SEG Chapter 25 System Structure

Winter 2007, rev. 2008SEG Chapter : Systems What is a system? Behavior Structure Real time systems

Winter 2007, rev. 2008SEG Chapter 27 What is a System? A system is part of real world that a person or group of persons during some time interval and for some purpose choose to regard as a whole, consisting of interrelated components, each component characterized by properties that are selected as being relevant to the purpose. A system is a purposeful collection of interrelated components that work together to achieve some objective.

Winter 2007, rev. 2008SEG Chapter 28 What is a System (2) A system is part of the real world. What constitutes a system is a matter of definition. Each component of a system may also be regarded as a system. A system is not just any unordered collection of components. A system has purpose.

Winter 2007, rev. 2008SEG Chapter 29 System Hierarchy

Winter 2007, rev. 2008SEG Chapter 210 A Simple Intruder Alarm System

Winter 2007, rev. 2008SEG Chapter 211 System Description Two purposes –To describe the functional behavior so that it can be fully understood –To describe the realization so that the system may be produced System vs system description

Winter 2007, rev. 2008SEG Chapter 212 System and System Description

Winter 2007, rev. 2008SEG Chapter 213 Behavior The behavior of a system is the development of states and state transitions generated by actions of the system during the time interval in which it is studied. Behavior is a dynamic development over time. Actually occurring in real world. Approximation: behavior consists of actions that change state (value) of variables.

Winter 2007, rev. 2008SEG Chapter 214 A Segment of Behavior

Winter 2007, rev. 2008SEG Chapter 215 Structure The structure of a system is the aspects of the system which stay invariant during the time interval in which it is studied. Structure is the way things hold together for some time. pp 30-31

Winter 2007, rev. 2008SEG Chapter 216 Real Time Systems A system is a real time system if it has a role with time constraints. A real-time system is a system that is required to react to stimuli from the environment within time intervals dictated by the environment.

Winter 2007, rev. 2008SEG Chapter 217 A Simple Fluid Control System (real-time) Pipe Flow meter Valve Interface Computer Time Input flow reading Processing Output valve angle

Winter 2007, rev. 2008SEG Chapter 218 A Grain-Roasting Plant (real-time) Fuel Tank Furnace Bin Pipe fuel grain

Winter 2007, rev. 2008SEG Chapter 219 A Process Control System (real-time) Process Control Computer Chemicals and Materials Valve Temperature Transducer Stirrer Finished Products PLANT

Winter 2007, rev. 2008SEG Chapter : Techniques to Manage Complexity Abstraction Projection Aggregation and partition Generalization and specialization

Winter 2007, rev. 2008SEG Chapter 221 Abstraction To ignore some aspects of a phenomenon in order to describe (and understand) others more clearly. Opposite of concrete or physical The abstractions should be clear and precise, lead to efficient implementation, and support the continuing development and reuse.

Winter 2007, rev. 2008SEG Chapter 222 Projection In projections we look at the system from different angles. A projection is a description of a system as it is observed at subset of its interfaces. Only the observable interfaces are visible, while the others are hidden.

Winter 2007, rev. 2008SEG Chapter 223 Aggregation and Partitioning (I) All non-trivial systems are composed from components. The process of lumping components together to form a whole is called aggregation. The opposite process of decomposing a whole into parts is called partitioning.

Winter 2007, rev. 2008SEG Chapter 224 Aggregation and Partitioning (II)

Winter 2007, rev. 2008SEG Chapter 225 Generalization and Specialization In the real world there are huge amounts of similar subjects. Rather than describing and understanding all individuals in full detail, we may describe and understand them in terms of similarity. Type are conceptual entities that we use to structure our descriptions and thoughts. Individual or subtype is an instance of a type.

Winter 2007, rev. 2008SEG Chapter 226 A Generalization Hierarchy

Winter 2007, rev. 2008SEG Chapter 227 Type and Subtype

Winter 2007, rev. 2008SEG Chapter 228 Inheritance and Specialization

Winter 2007, rev. 2008SEG Chapter : Behavior Description: the Problem The quality of a real-time system is determined to a very large extent by its behavior. Behavior is the most difficult system aspect to describe, due to its dynamic and transient nature. How can we represent a dynamic and possibly infinite behavior in a static and finite way?

Winter 2007, rev. 2008SEG Chapter 230 Behavior Description: Example

Winter 2007, rev. 2008SEG Chapter 231 Behavior Description: Focus State-oriented –focus on states and action instances –each state is represented by a node –each action instance is represented by a branch Action-oriented –focus on action types and variables –states need not be described at all –the states may be found by analyzing the actions

Winter 2007, rev. 2008SEG Chapter : Some Description Approaches Abstract description Entity relationship description SOON notation Data flow diagrams Finite state machine

Winter 2007, rev. 2008SEG Chapter 233 Abstract Description Many different approaches to abstract system description Conflict between the need to formalize and the need to understand The abstract description methods that have had the strongest penetration so for have been those that emphasize the needs of human audience.

Winter 2007, rev. 2008SEG Chapter 234 Entity Relationship Description

Winter 2007, rev. 2008SEG Chapter 235 Entity Relationship Diagram Legend

Winter 2007, rev. 2008SEG Chapter 236 Another Entity Relationship Diagram

Winter 2007, rev. 2008SEG Chapter 237 SOON Notation (used in book by Braek)

Winter 2007, rev. 2008SEG Chapter 238 The SOON notation has a clear separation between types and instances it allows us to represent individuals and types explicitly and not implicitly as in ER diagrams. Type Definition

Winter 2007, rev. 2008SEG Chapter 239 UML Class Diagram

Winter 2007, rev. 2008SEG Chapter 240 Data Flow Diagrams

Winter 2007, rev. 2008SEG Chapter 241 UML Activity Diagram (related to Dataflow Diagrams)

Winter 2007, rev. 2008SEG Chapter 242 Use Case Maps A notation (with roots in Ottawa) which is semantically similar to Activity Diagrams. Here is the same example: Receive Order Fill Order Send Invoice Ship Order Make Payment Acccept Payment Close Order Warehouse Office Client [ Order rejected ] [ Order accepted ]

Winter 2007, rev. 2008SEG Chapter 243 Concepts describing requirements Each Use Case is a scenario –Actions done by actors in some given order Action: Activity / Responsibility Actor: Swimlane / Component Order: sequence, alternatives, concurrency, arbitrary control flows (similar to Petri nets) Abstraction: refinement of activity / Plug-in Data-Flow: Object flow / not in UCMs. Question: what type of data is exchanged (an extension of control flow) –Input assertions for input data flow –Output assertions for output data flow –Conditions for alternatives (also in UCMs)

Winter 2007, rev. 2008SEG Chapter 244 Finite State Machine

Winter 2007, rev. 2008SEG Chapter 245 FSM A finite set of inputs, I : A finite set of outputs, O ; A finite set of state, S ; A next state function, F S : S  I  S ; An output function, F O : S  I  O* ; A designated initial state, Initial.

Winter 2007, rev. 2008SEG Chapter : The Methodology Presented Here

Winter 2007, rev. 2008SEG Chapter 247 Summaries of Notations

Winter 2007, rev. 2008SEG Chapter : The SOON Notation SISU Object-Oriented Notation Used to describe structures where SDL is not appropriate Less formal and does not enforce SDL semantics

Winter 2007, rev. 2008SEG Chapter 249 SOON Symbols

Winter 2007, rev. 2008SEG Chapter 250 SOON Syntax