Lecture Notes on Object Modeling

Lecture Notes on Object Modeling

Object-Oriented Software Engineering Using UML, Patterns, and Java Final Course Review: Single Semester Course or First Semester Questions Outline for Today 1. Reality and modeling, Abbots Technique 2. Different ways to use models 3. Model Transformations 4. Software Development Activities 5. Design Patterns 6. Object Design 7. Mapping Object Models 8. Software process 9. Methodologies 10.Scheduling 11.Estimation 12.Continuous Integration

Reality and Model Reality R Real things, people, processes happening during some time, relationships between things Model M Abstractions from things, people , processes and relationships between these abstractions The things really exist or can be abstractions (ideas) as well. Verification vs Validation of models Object ImplemenSystem Analysis Design tation Design MImpl M

M MSystem R Object Analysis fR R fMA fMS MAnalysis Validation fMD M I R

MObject MSystem Verification Verification fM fR fImpl M I R MImpl Verification Why Modeling?

We use models To abstract away from details in the application domain, so we can draw complicated conclusions in the reality by performing simple steps in the model To get insights into the past or presence To make predictions about the future We can model all kinds of systems Natural systems (Astronomy, Astrophysics) Human beings (Psychology, Sociology, HCI, CSCW) Artificial Systems (Computer Science) Event philosophical ideas can be modeled System Modeling Functional model Scenarios, use case model

Structural model Class diagrams, instance diagrams, component diagrams, deployment diagrams Dynamic model Sequence diagrams, statechart and activity diagrams When is a Model Dominant? Object model: The system has classes with nontrivial states and many relationships between the classes Dynamic model: The model has many different types of events: Input, output, exceptions, errors, etc. Functional model: The model performs complicated transformations (eg. computations consisting of many steps).

Which model is dominant in these applications? Compiler Database system Spreadsheet program Mapping parts of speech to model components (Abbots Technique) Example Part of speech UML model component Monopoly Proper noun object Toy

Improper noun class Buy, recommend Doing verb operation is-a being verb inheritance has an having verb

aggregation must be modal verb constraint dangerous adjective attribute enter transitive verb operation depends on

intransitive verb Constraint, class, association Using Abbots Technique: Platos Model of Reality Plato Platos model of reality: Reality consists of many Things A Thing can be either a Particular Thing or a Form Beauty is not a particular thing, but it is real and exists. How does the corresponding system model look like? Hint: Use Abbots Technique

Platos Model of Beauty Plato Platos model of reality: Reality consists of many particular things and many forms A Thing can be either a Particular Thing or a Form Beauty is not a particular thing, but it is real and exists. Aristotles View of Reality Aristotle Aristotles model of reality: Reality consists of many particular things called substances Each substance is composed of form and matter

Aristotles View of Beauty Aristotle Aristotles model of reality: Reality consists of many particular things called substances Each substance is composed of form and matter Beauty is real, but it does not exist on its own, it is always part of a substance. Comparison of Platos and Aristotles Views Plato Aristotle Comparison of Platos and Aristotles Views

Thing Matter Plato Aristotle UML: Notation for Models Baloo:Baer Hellabrunn Zoo:Zoo Reality Mammal 40 Idea

:Baer Baer Taxonomy Models can be used in 3 Ways Models support three different types of activities: Communication: The model provides a common vocabulary. An model is communicated informally Target is a human being (developer, end user) Analysis and Design: Models enable developers to specify and reason about a future system Target is a tool (CASE tool, compiler) Archival: Compact representation for storing the design and rationale of an existing system Target is the human (analysis, project manager) Example of a Conceptual Model (Napkin Design)

Example of a Model for Analysis and Design: Controlled Items in a CVS System * Controlled Item * CM Aggregate Configuration Item Version * Promotion Release

* Master Directory Repository An Object-Oriented View of the OSI Model Application The OSI Model is a closed software architecture (i.e., it uses opaque layering) Each layer can be modeled as a UML package containing a set of classes available for the layer above

Presentation Format Session Connection Transport Message Network Packet DataLink Physical

Frame Bit Topics 1. 2. 3. 4. 5. 6. 7. 8. 9. Reality and modeling, Abbots Technique Different ways to use models Model Transformations Design Patterns System Design Object Design

Mapping Object Models Software process Methodologies Model Transformations Object-Oriented modeling means transformation of a single model throughout the software development activities Forward Engineering, Reverse Engineering, ReEngineering, Refactoring 4 Different Types of Transformations Program (in Java) Yet Another System Model Another System Model Forward engineering

Refactoring Model transformation System Model (in UML) Reverse engineering Model space Another Program Source code space Example of a Model Transformation: Pull up Field Object model before transformation:

LeagueOwner +email:Address Advertiser +email:Address Player +email:Address Object model after transformation: User +email:Address LeagueOwner Advertiser Player Example of Refactoring: Pull Up

Field public class User { private String email; } public class Player { private String email; //... } public class LeagueOwner { private String eMail; //... } public class Advertiser { private String email_address; //... } public class Player extends User { //... } public class LeagueOwner extends User

{ //... } public class Advertiser extends User { //... } Examples: Model Transformation & Forward Engineering Model Transformations Goal: Optimizing the object design model Collapsing objects Delaying expensive computations Forward Engineering Goal: Implementing the object design model in a programming language Mapping inheritance Mapping associations Mapping contracts to exceptions Mapping object models to tables

Collapsing Objects Object design model before transformation: Person SocialSecurity number:String Object design model after transformation: Person SSN:String Turning an object into an attribute of another object is usually done, if the object does not have any interesting dynamic behavior (only get and set operations). Delaying expensive computations Object design model before transformation: Image filename:String

data:byte[] paint() Object design model after transformation: Image Proxy Pattern! filename:String paint() ImageProxy filename:String paint() image 1 0..1 RealImage

data:byte[] paint() Examples of Model Transformations and Forward Engineering Model Transformations Goal: Optimizing the object design model Collapsing objects Delaying expensive computations Forward Engineering Goal: Implementing the object design model in a programming language Mapping inheritance Mapping associations Mapping object models to tables Forward Engineering: Mapping a UML Model into Source Code Java provides the following constructs:

Overwriting of methods (default in Java) Final classes Final methods Abstract methods Abstract classes Interfaces. Realizing Inheritance in Java Realisation of specialization and generalization Definition of subclasses Java keyword: extends Realisation of simple inheritance Overwriting of methods is not allowed Java keyword: final

Realisation of implementation inheritance Overwriting of methods No keyword necessary: Overwriting of methods is default in Java Realisation of specification inheritance Specification of an interface Java keywords: abstract, interface Mapping Inheritance Object design model before transformation: User -email:String +getEmail():String +setEmail(e:String) +notify(msg:String) LeagueOwner -maxNumLeagues:int +getMaxNumLeagues():int

+setNaxNumLeagues(n:int) Source code after transformation: public class User { private String email; public String getEmail() { return email; } public void setEmail(String value){ email = value; } public void notify(String msg) { // .... } } public class LeagueOwner extends User { private int maxNumLeagues; public int getMaxNumLeagues() { return maxNumLeagues; }

public void setMaxNumLeagues (int value) { maxNumLeagues = value; } } Examples of Model Transformations and Forward Engineering Model Transformations Goal: Optimizing the object design model Collapsing objects Delaying expensive computations Forward Engineering Goal: Implementing the object design model in a programming language Mapping inheritance Mapping associations Mapping contracts to exceptions Mapping object models to tables

Mapping Associations 1. 2. 3. 4. Unidirectional one-to-one association Bidirectional one-to-one association Bidirectional one-to-many association Bidirectional many-to-many association. Unidirectional one-to-one association Object design model before transformation: Advertiser 1 1 Account

Source code after transformation: public class Advertiser { private Account account; public Advertiser() { account = new Account(); } public Account getAccount() { return account; } } Bidirectional one-to-one association Object design model before transformation: Advertiser 1 1 Account

Source code after transformation: public class Advertiser { /* account is initialized * in the constructor and never * modified. */ private Account account; public Advertiser() { account = new Account(this); } public Account getAccount() { return account; } } public class Account { /* owner is initialized * in the constructor and * never modified. */ private Advertiser owner; publicAccount(owner:Advertiser) {

this.owner = owner; } public Advertiser getOwner() { return owner; } } Bidirectional many-to-many association Object design model before transformation Tournament * * Player Source code after transformation public class Tournament { private List players;

public Tournament() { players = new ArrayList(); } public void addPlayer(Player p) { if (!players.contains(p)) { players.add(p); p.addTournament(this); } } } public class Player { private List tournaments; public Player() { tournaments = new ArrayList(); } public void addTournament(Tournament t) { if (!tournaments.contains(t)) { tournaments.add(t); t.addPlayer(this);

} } } Mapping Object Models to Relational Databases UML object models can be mapped to relational databases The basic idea of the mapping: Each class is mapped to its own table Each class attribute is mapped to a column in the table An instance of a class represents a row in the table One-to-many associations are implemented with a buried foreign key Many-to-many associations are mapped to their own tables

Methods are not mapped Realization of associations Generic associations, inheritance Topics 1. 2. 3. 4. 5. 6. 7. 8. 9. Reality and modeling, Abbots Technique Different ways to use models Model Transformations Software Development Activities Design Patterns

Object Design Mapping Object Models Software process Methodologies Software Development Activities Object-Oriented modeling means transformation of a single model throughout the software development activities Software Development Activities Requirements Analysis System Design Object Design (Patterns) Testing Implementation

System Development as a Set of Activities System Model Application objects Solution objects Custom objects Problem Analysis Design - Object Design Off-the-Shelf Components - System Design

Existing Machine Requirements Analysis Questions 1. What are the transformations? Functional Modeling Create scenarios and use case diagrams - Talk to client, observe, get historical records 2. What is the structure of the system? Object Modeling Create class diagrams - Identify objects. - What are the associations between them? - What is their multiplicity? - What are the attributes of the objects? - What operations are defined on the objects? 3. What is its behavior? Dynamic Modeling Create sequence diagrams - Identify senders and receivers - Show sequence of events exchanged between objects. - Identify event dependencies and event concurrency. Create state diagrams

- Only for the dynamically interesting objects. Requirements Analysis 1. What are the transformations? Talk to the client Observe the end user Get historical records Create scenarios and use case diagrams Functional Modeling Requirements Analysis (contd) 2. What is the structure of the system?

Identify objects What are the associations between them? What is their multiplicity? What are the attributes of the objects? What operations are defined on the objects? Create class diagrams Object Modeling Requirements Analysis (contd) 3. What is the behavior of the system? Identify senders and receivers

Show sequence of events between objects Identify event dependencies and concurrency Are there dynamically interesting objects? Create sequence diagrams Create activity and state diagrams Dynamic Modeling From Analysis to System Design Nonfunctional Requirements 1. Design Goals Definition Trade-offs Functional Model 2. System Decomposition Layers vs Partitions Coherence/Coupling Functional Model

8. Boundary Conditions Initialization Termination Failure Dynamic Model 7. Software Control Monolithic Dynamic Event-Driven Object Model Model Conc. 5. Data 4. Hardware/ Processes 6. Global

Resource Management 3. Concurrency Software Mapping Handlung Special Purpose Systems Persistent Objects Identification of Access Control List Buy vs Build Filesystem vs Threads vs Capabilities Allocation of Resources Database Security Connectivity System Design Activities 1. Identify Design Goals - Identify Additional Nonfunctional Requirements - Discuss Trade-offs

2. Subsystem Decomposition - Layers vs Partitions - Coherence & Coupling 3. Identify Concurrency 4. Hardware/ 5. Persistent Data - Identification ofSoftware Mapping Management Parallelism (Processes, Threads) - Identification of Nodes -Storing Entity Special Purpose Systems Objects Buy vs Build Decisions

- Filesystem vs Network Connectivity Database 8. Boundary Conditions - Initialization - Termination - Failure. 7. Software Control - Monolithic - Event-Driven - Conc. Processes 6. Global Resource Handlung - Access Control

- ACL vs Capabilitie - Security How the Analysis Models influence System Design Nonfunctional Requirements => Definition of Design Goals Functional model => Subsystem Decomposition Object model => Hardware/Software Mapping, Persistent Data Management Dynamic model => Identification of Concurrency, Global Resource Handling, Software Control Finally: Hardware/Software Mapping => Boundary conditions

Other System Design Topics Examples of Design Goals Architectural Styles and Architectures Open and closed Architectures Layering vs Partitioning Good Design: Coupling and Coherence Hardware Software Mapping Mapping object models to relational databases Access Control Object Design

Developers play different roles during object design Developer Class User Call Class Class Implementor Realize Class Class Extender Refine Class Object Design Activities Select Subsystem Specification

Identifying missing attributes & operations Reuse Identifying components Specifying visibility Adjusting components Specifying types & signatures Identifying patterns Specifying constraints Specifying exceptions Applying patterns The use of Inheritance Inheritance is used to achieve two different goals Description of Taxonomies

Interface Specification Description of Taxonomies Used during requirements analysis Activity: identify application domain objects that are hierarchically related Goal: make the analysis model more understandable Interface Specification Used during object design Activity: identify the signatures of all identified objects Goal: increase reusability, enhance modifiability and extensibility Metamodel for Inheritance Inheritance Analysis activity Taxonomy

Inheritance detected by specialization Inheritance detected by generalization Object Design Inheritance for Reuse Specification Inheritance Strict Inheritance Implementation

Inheritance Contraction Realizing Inheritance in Java Realisation of specialization and generalization Definition of subclasses Java keyword: extends Realisation of simple inheritance Overwriting of methods is not allowed Java keyword: final Realisation of implementation inheritance Overwriting of methods No keyword necessary: Overwriting of methods is default in Java Realisation of specification inheritance Specification of an interface Java keywords: abstract, interface

Model-based Testing Test System Test Case MoneyTest is the test context MoneyUnitTest is the test case SUT TestContex t Deployment Diagram of a Continuous Integration System Other Topics

Requirements Analysis vs. Object Design Component-Based Software Engineering COTS-Development Reuse (White box vs black box reuse) Generalizations and Specification Delegation vs Inheritance The Use of Inheritance Taxonomies Interface Specification Implementation Inheritance vs Specification Inheritance Push vs Pull Notification, Push-Update-Notification Topics 1. 2.

3. 4. 5. 6. 7. 8. 9. Reality and modeling, Abbots Technique Different ways to use models Model Transformations Software Development Activities Design Patterns Object Design Mapping Object Models Software process Methodologies Design Patterns Composite: Model dynamic aggregates

Adapter: Interface to existing systems (legacy systems) Bridge: Interface to existing and future systems Facade: Interface to subsystems, hiding the internals Proxy: Provide Location transparency Command: Encapsulate control flow Observer: Publisher/ subscribe mechanism Strategy: Support a family of algorithms Abstract Factory: Provide manufacturer independence

Builder: Hide a complex creation process Template: Provide the workflow for a solution Design Patterns Structural Patterns Focus: Composing objects to form larger structures Problems solved: Realize new functionality from old functionality Behavioral Patterns Focus: Assignment of responsibilities to objects Problem solved: Tight coupling to particular algorithms Creational Patterns Focus: Creation of complex objects Problems solved: Hide how objects are created or put together Taxonomy for Design Patterns

Patterns can be combined: Example JUnit * Test TestResult Command Pattern run(TestResult) Composite Pattern Template Method Pattern Adapter Pattern TestCase

testName:String run(TestResult) setUp() tearDown() runTest() ConcreteTestCase setUp() tearDown() runTest() TestSuite run(TestResult) addTest() TestedUnit Application Domain vs System Domain Application Domain

Solution Domain System Model System Model Summary Display TrafficControl Aircraft TrafficController FlightPlan Airport MapDisplay FlightPlanDatabase TrafficControl Example: Observer Pattern

Subject subscribe(subscriber) unsubscribe(subscriber) notify() observers * update() Solution Domain (Design Knowledge) ConcreteSubject ConcreteObserver state getState()

setState() Observer observeState Application Domain (Application Knowledge) update() The Subject (Publisher) represents the entity object Observers (Subscribers) attach to the Subject by calling subscribe() Each Observer has a different view of the state of the entity object The state is contained in the subclass ConcreteSubject The state can be obtained and set by subclasses of type ConcreteObserver. Observer Pattern Models a 1-to-many dependency between objects Connects the state of an observed object, the subject with

many observing objects, the observers Usage: Maintaining consistency across redundant states Optimizing a batch of changes to maintain consistency Three variants for maintaining the consistency: Push Notification: Every time the state of the subject changes, all the observers are notified of the change Push-Update Notification: The subject also sends the state that has been changed to the observers Pull Notification: An observer inquires about the state the of the subject Also called Publish and Subscribe. Model-View-Controller Architectural Style Subsystems are classified into 3 different types Model subsystem: Responsible for application domain knowledge

View subsystem: Responsible for displaying application domain objects to the user Controller subsystem: Responsible for sequence of interactions with the user and notifying views of changes in the model Class Diagram Controller initiator * 1 repository Model View subscriber

1 notifier * Better understanding with a Collaboration Diagram Access Matrix Implementations Access control list Associates a list of (actor,operation) pairs with each class to be accessed. Every time an instance of this class is accessed, the access list is checked for the corresponding actor and operation. Capability Associates a (class,operation) pair with an actor. A capability provides an actor to gain control access to an object of the class described in the capability.

Modeling Boundary Conditions Boundary conditions are best modeled as use cases with actors and objects We call them boundary use cases or administrative use cases Actor: often the system administrator Interesting use cases: Start up of a subsystem Start up of the full system Termination of a subsystem Error in a subsystem or component, failure of a subsystem or component. Contracts Contracts enable the caller and the provider to share the same assumptions about the class

A contract is an exact specification of the interface of an object A contract includes three types of constraints Invariants Preconditions (rights) Postconditions (obligations) Contract restrict the model space They constrain what can be instantiated OCL: Object Constraint Language Formal language for expressing constraints over a set of objects and their attributes Part of the UML standard For expressing constraints that cannot be modeled in UML Declarative No side effects, No control flow Based on Sets and Multi Sets OCL expressions are predicates that return True or

False Evaluated in a specified context, either in the context of a class or in the context of an operation All constraints apply to all instances Specifying Model Constraints Local attribute navigation * context Tournament inv: end - start <= Calendar.WEEK Directly related class navigation +start:Date +end:Date +getActivePlayers() {ordered} * tournaments

context Tournament::acceptPlayer(p) pre: league.players->includes(p) Tournament +start:Date +end:Date +acceptPlayer(p:Player) * tournaments Indirectly related class navigation context League::getActivePlayers post: result=tournaments.players->asSet League players * * players

Player +name:String +email:String Access Matrix The rows of the matrix represents the actors of the system The column represent classes whose access we want to control Access Right: An entry in the access matrix. It lists the operations that can be executed on instances of the class by the actor. Lasts Hints If a topic was not mentioned here, that does not imply that it will not appear in the exam Scope of the exam: Chapter 1 11, Appendix A and B in the text book Form a study group Formulate questions that others in the group must answer Rotate questioner and answerer

Some typical questions: Here is a problem statement or a napkin design of a system. Model it in UML What is? Name advantages and/or disadvantages of ... Here is some code. Reverse engineer the model Here is a model. Forward engineer the code Object-Oriented Software Engineering Using UML, Patterns, and Java Final Course Review: Second Semester Questions Rationale Management

What is rationale? Why is it critical in software engineering? Use of rationale in software development Issue Models Resolutions Example of an Issue Model input?:Issue addressed by addressed by text-based:Proposal raises display?:Issue meets addressed by

point&click:Proposal meets terminal?:Issue fails usability$:Criterion The time to input commands should be less than two seconds. fails availability$:Criterion The CTC system should have at least a 99% availability. Software Process Key Question: How do we control software development? Through organizational maturity (Humphrey) Defined process, Capability Maturity Model (CMM) Through agility (Schwaber)

Software development is empirical in nature Cannot be modeled with a defined process Should be described with an empirical process control model Example of a Lifecycle Model: The VModel The Key Problems in Software Engineering The three main challenges in software development How do we harness complexity? How do we react to change? How do we deal with uncertainty? Methodologies Methodologies Software methodologies provide Guidance and general principles for dealing with complexity, change and uncertainty

Strategies for selecting methods and tools in a given project environment Guidance what to do when things go wrong Methodologies (contd) Key questions in a methodology How How How How How How much

much much much much much involvement of the customer? planning? reuse? modeling? process? control and monitoring? WBS, Estimation and Scheduling

Determining Work and Tasks Sizes Different Approaches for developing WBSs Notations for Work Breakdown Structures Heuristics for Developing Good WBS Boehms Cone of Uncertainty Dependency Diagrams and Notations Critical Path Analysis (Forward Path and Backward Path Analysis) Burndown Charts Computing a critical path Activity 1 Activity 2 t1 = 5 t2 = 1 Start

t=0 End t=0 Activity 3 t3 = 1 Activity 4 Activity5 t4 = 3 t55 = 2 Critical path with bold and red arrows Additional Topics Icebreaker

Basic Concepts (Work Package, WBS, Task, Activity, Project Baseline, Release, Promotion, Configuration Management, Deliverable, Audience List, etc, etc) Structures in Organization Functional vs Matrix vs Project-based Organizations Architecture-centric Project Management Agile Project Management, Situated actions Setting up a Project: Example 1. Define Subsystem decomposition (TopLevel Design) 2. Determine the Work Breakdown Structure Develop System UserInterface

Control Database Develop UserInterface Develop Control Subsystem Develop Database Subsystem Setting up a Project: Example 2. Determine the Work Breakdown Structure Develop System Develop UserInterface

3. Set up the Teams UserInterface :Team Develop Control Subsystem Develop Database Subsystem Control :Team Database :Team Binding Roles To People Project To-Do List (from your WBS) Item 1 Item 2

Item 3 Role 1 Item 1 Item 2 Item 9 Item 5 Item 6 Item 7 Item 8 To-Do Role Bindings are made during Project-Initiation Phase Role 1 Role 2 Role 2 Item 4 Item 5

Item 7 Item 4 Item 9 Person A Person B Role 3 Role 3 Item 3 Item 6 Item 8 Roles-Person Bindings are made during Initial Planning phase (First team meeting, etc ) Key Concepts for Binding Roles to

People Responsibility The commitment to achieve specific results Redefinition of role: A role is a set responsibilities Delegation Rebinding a responsibility assigned to one person (including yourself) to another person. Authority The ability to make the binding decisions between roles and people Accountability Tracking a task performance to a person Structures in Organizations An organization usually has 3 different types of associations between organizational units Reporting structure Shows how status information is reported

Decision structure Shows how decisions are propagated Communication structure Shows how information is exchanged. Scrum (Napkin Design) Scrum Master Daily Scrum meeting Potentially shippable Product Increment Dealing with Uncertainty, Complexity and Change (Agile Manifesto) Individuals and Interactions

Working Software Customer Collaboratio n Responding to Change Processes and Tools Comprehensive Documentation Contract Negotiation Following a Plan Dealing with Uncertainty, Complexity and Change (Agile Manifesto) Royce Scrum

Individuals and Interactions Working Light, Software Agile Customer Collaboratio n Extreme Programming Responding to Change Processes and Tools Comprehensive Documentation Contract Negotiation

Heav y Following a Plan Waterfall Lasts Hints If a topic was not mentioned here, that does not imply that it will not appear in the exam Scope of the exam: Chapter 12 16 in the text book Form a study group Formulate questions that others in the group must answer Rotate questioner and answerer Some typical questions: Here is a problem statement or a napkin design of a system. Model it in UML What is? Name advantages and/or disadvantages of ... Here is some code. Reverse engineer the model

Here is a model. Forward engineer the code.

Recently Viewed Presentations

  • Ecosystems - Next Generation Science Standards

    Ecosystems - Next Generation Science Standards

    By doing this, we can help make our ecosystem a sustainable living space for everybody! - Explain the benefits and describe a real life example for each point e.g gazelles in savanna, dolphins herding schools of fish, elephants living near...
  • Redesigning our seas and coasts? A tale of

    Redesigning our seas and coasts? A tale of

    Redesigning our seas and coasts? A tale of adaptive management Prof Laurence Mee Scottish Association for Marine Science
  • Behavior Change as - Cengage

    Behavior Change as - Cengage

    Defining Behavior Behavior is what individuals do—their observable behavior. Behavior can be verbal or nonverbal. Considering covert behavior. Things that are not behavior Three-Term Contingency Applied Behavior Analysis ABA is concerned with a person's behavior and how environmental factors affect...
  • www.fleetwoodasd.k12.pa.us

    www.fleetwoodasd.k12.pa.us

    The last renovation in 1992 added on classrooms, a gymnasium, art room, music room and computer room. The new additions have been thoroughly enjoyed by all students and staff. Below is a school wide project that was created by our...
  • VT PowerPoint Template5

    VT PowerPoint Template5

    Dr. Wilcke gives a free 30 minute consultation with whomever registers to download the subset to help enable a smooth implementation. Various release formats available on our website. These are available after you obtain a login from Dr. Wilcke. XML...
  • Overview of the History of Canadas Immigration Policy

    Overview of the History of Canadas Immigration Policy

    Overview of the History of Canada's Immigration Policy Researched by Janet Dench Compiled by Loly Rico and Kemi Jacobs Canadian Council for Refugees
  • Figures-Chapter 13

    Figures-Chapter 13

    The process should have a defined process model that sets out the activities in the process and the documentation that is to be produced during these activities. ... Triple modular redundancy ... This leads to the well-known 'bounded buffer' vulnerability...
  • Modern Civil Rights Movement

    Modern Civil Rights Movement

    On the very eve of the day Lucy and her friend (who had married to become Pollie Myers Hudson) were to register, the University Board of Trustees rejected Hudson on the grounds of her "conduct and marital record", but reluctantly...