Presentations from Institiúid Teicneolaíochta, Ceatharlach (Institute of Technology, Carlow)

* System Sequence Diagrams 1 Introduction A system sequence diagram (SSD) is a fast and easily created artifact that illustrates input and output events related to the systems under discussion. They are input to operation contracts and, most importantly, object design. We can relate SSDs to the other models we have seen so far

* Other Requirements 1. Introduction Recall: in the UP requirements are categorised according to the FURPS+ model: Functional : features; Usability : human factors, help, documentation; Reliability : frequency of failure, recoverability; Performance : response times, throughput, resource usage; Supportability : adaptability, maintainability, internationalisation; in addition the ‘+’ in FURPS+ indicates ancillary requirements or constraints such as: Implementation : language and tools, hardware restrictions; Interface : interfacing constraints; Web support : user forum, demo videos; Legal : licensing;

* The Strategy Pattern 1 Sim Duck Application Example This example is an existing game about ducks (they can swim, quack etc) that Joe is responsible for maintaining. Note, that there are many other Duck subtypes not shown below.

* Domain Models and Class Diagrams 1 Introduction Identification of the necessary classes to support the allocated use cases; Domain models are a stepping stone to design:

* The Decorator Pattern 1. The Problem Inheritance can be overused: it has to be decided at compilation time and thus objects cannot gain new responsibilities at runtime. Using the decorator pattern will allow us to give objects new responsibilities at runtime without making any code changes to the underlying classes. 2. A Coffee Shops Example A new coffee retailer is launching a number of coffee shops around the world and need a coffee ordering system. A coffee can be a “House Blend”, “Dark Roast”, “Decaf” or “Espresso”; But many condiments can also be added : Steamed Milk, Mocha, Soy, Whipped Cream etc. and combined together; The cost of the beverage takes into account the coffee but also the condiments added.

* Evolutionary Requirements 1. Definition : Requirements “Requirements are capabilities and conditions to which the system, and more broadly the project, must conform” The UP does not attempt to fully define the requirements before programming but instead, promotes a systematic approach to finding, documenting, organising and tracking the changing requirements of a sytem: This is about embracing change; Tackling software development as a problem solving activity; It also emphasises a disciplined way to handling change: iteratively and skilfully yes but not in an haphazard or sloppy way. The UP-way entails continuous, multi-way, communication between the developpers, the clients and all other stakeholders to discover and track requirements but also the documenting of requirements: the UP “manage changing requirements”.

* UMLet – Practical UMLet can be easily customised, first: Complete UMLet's custom element tutorial (access via UMLet's menu Custom Elements); You can also change a palette in UMLet by first selecting it in the palette menu, and then chossing the edit current palette option in the palette menu. Customise the palette sequence_palette by adding a return message arrow to it such as : UMLet is very flexible ...

Chapter 25: UML State Machine Diagrams and Modeling

25.1 Introduction UML State Machine Diagrams represent Finite State Machines (FSM). FSMs have long been used in software development and are not a OO technology. They can be used in all projects (Gaming or not). For games they are particularly useful to represent the AI of Non-Player-Characters. Many notations for FSMs exist: we mostly use UML notation. We will only seen basic FSMs here: more complex ones (e.g. non-deterministic FSMs) are needed for games AI. FSMs are good as modeling/documenting tools and map relatively easily to code;

Chapter 18: Object Design Examples with GRASP

18.1 Introduction We will see a systematic way to perform OOD using patterns, and a responsibility-driven approach: We will justify all our choices; We will provide a detailed method; Once these skills are learned, and especially in an agile approach, such level of justification is not necessary: Basic OOD becomes automatic in one’s mind after a while; More time can then be devoted to more difficult design decisions; But, for now, we’ll see the basics first...

Chapter 21: Elaboration Iteration 1 Conclusions

21.1 Review of Iteration 1 We have nearly concluded the first iteration of the elaboration phase. A few review facts: The UP is made up of different phases: Inception, Elaboration, Construction and Transition Phases; Inception : approximate vision, business case, scope, vague estimates; Elaboration : refined vision, use cases, iterative development of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates; Construction : iterative implementation of the remaining lower risks aspects; Transition : beta tests, deployment;

Chapter 09: Design Techniques

How, given a specification of the requirements produced during the analysis phase of the project, can we produce, during the design phase of the project, design documents that will allow coding to take place? We must respect the requirements; We have to write the design documents as if someone else will code and test the application (typical for medium to large projects); We will see in turn: Data design; Architectural design; Interfaces design; Procedural design;

* UMLet – Practical UMLet is a UML sketching tool; It is available at http://www.umlet.com/ Similar UML sketching tools exists (notably Violet at http://www.horstmann.com/violet/); It allows for the rapid creation of UML diagrams; UMLet is quite intuitive to use and is easily customisable (once one gets used to the text notation); It requires a Java Runtime Environment;

* Chapter 03: Case Studies 3.1. What is and is not Covered in the Case Studies? Traditional business software applications include UI elements, core application logic, database access and links to external software or hardware: To learn about OOA and D using UML we will focus on the core application logic layer; These core skills can transfer to other layers and other application styles; See Fig 3.1 for simple layer architecture scheme While Games architecture is usually quite diferrent the OOA and D skills as well as the development process (if iterative, evolutionary and agile) are identical. Also, while for games we would typically apply an agile way of doing things, we must learn to do OOA and D in detail first: It makes it easier to eliminate unnecessary details later, once we are proficient in OOA and D;

Defect testing (aka dynamic verification) The only objective of defect testing is : to find errors in the system under test.

Intro to Computer Security

1 Computer crime is a serious and growing problem In 1994, The Yankee Group estimated that computer security breaches cost businesses based in the USA $5 billion annually! In 1995, this estimate had risen to $10 billion! A survey by the Computer Security Institute, again in 1995, again in the USA, showed that: 25% of the companies surveyed had experienced a computer crime within the preceding 12 months Theft of private business information rose by 260% over the five year period from 1988 to 1993

Learning Ruby - 4 Learning Ruby - 4 Ruby Code Blocks

Learning Ruby - 7 Learning Ruby - 7 Methods

* Iteration 1 - Basics 1 Introduction The requirements for first iteration: are a subset of the requirements as described by the use cases, the vision, and the supplementary specification; Subsequent iterations will grow these until a full system is implemented; The current requirements are not complete, they will evolve and benefit from feedback … 2 Planning the Iterations After the initial inception phase, the most important software requirements have been identified, some of which have been detailed. Other requirements remain to be discovered; Most will need further analysis;

* Iterative, Evolutionary, and Agile 1. Introduction Iterative because the entire project will be composed of min-projects and will iterate the same activities again and again (but on different part of the project) until completion. Evolutionary (or incremental) because the software grows by increments (to be opposed to the traditional, and somewhat old-fashionned, Waterfall model of software development). Agile because we will use a light approach to software development rather than a very rigid one (which may be needed for a safety-critical system for example) This kind of approach seems better at treating software development as a problem solving activity; also the use of objects makes it amenable. Explain Iterative, Evolutionary, Agile

Login using your SlideFinder account

Or use your third party provider to login

Universities > Ireland Showing 1 - 20 of 127 items

Institiúid Teicneolaíochta, Ceatharlach (Institute of Technology, Carlow)

Chapter 25: UML State Machine Diagrams and Modeling

Chapter 18: Object Design Examples with GRASP

Chapter 21: Elaboration Iteration 1 Conclusions

Chapter 09: Design Techniques

Intro to Computer Security

Learning Ruby - 4

Learning Ruby - 7

Learn about us

Universities

Slides by language

Tools