COMP2110 Software Design in 2004 lecture 09 High level design about assignment 2 high level design example: Encounter

About assignment 2 deliverables quality presentation week 7 working in small teams Details will be published later today.

Software Engineering Roadmap Develop Architecture/ High level design Identify corporate practices Develop Detailed Design Plan project Analyze requirements Maintain Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Begin Selecting a Basic Architecture One way to ... 1. Develop a mental model of the application at a high level – creative invention as if it were a small application e.g., personal finance application ... … “works by receiving money or paying out money, in any order, controlled through a user interface”. 2. Decompose into the required components look for high cohesion & low coupling … decomposes into Assets, Suppliers, & Interface. 3. Repeat this process for the components Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Cohesion and coupling a principle of quality design how to divide systems into modules modules should have strong cohesion: “hang together” logically, have a common theme, have more interaction (associations, uses relationships) between things within the same module than with things outside and there should be weak coupling between modules small interfaces thin interfaces few dependencies – easy to separate, reuse, replace

Cohesion and Coupling   Bridge High cohesion Low coupling component 1 2 3 4 component Bridge 5 6 High cohesion Low coupling   Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

High level design: module example BusCatcher route and service manager message stream handler user interface manager buttons display system clock alarm control audible alarm wireless interface

High level design: module example (2) askRoute askService askDelay route and service manager ETAlist ? promptSelect message stream handler * busETA userSetting user interface manager routeNo estTime getTimeOfDay setAlarmDelay clearAlarm display buttons wireless interface alarm control audible alarm system clock

UML Notation … and … Typical Implementation package MyPackage; abstract class AbstractClass . . . . class DerivedClass extends AbstractClass { int att; . . . . . void myFunction( ReferencedClass r ) { . .. } } package of classes MyPackage abstract class AbstractClass inheritance DerivedClass att: int myFunction() attribute operation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Modules, packages & high level design what Parnas refers to as “abstract modules” and design standards call “modules” may be seen in OO languages as “packages” - Java “clusters” – Eiffel packages – UML or they may be groupings in the design document and in the file system, with no language structure route and service manager This package contains 3 classes named busETA ETAlist userStates routeNo setTime busETA ETAlist userSetting

Architecture and Modularization of Encounter Role-playing Game EncounterGame EncounterGame EncounterCharacters EncounterCast EncounterEnvironment EncounterEnvironment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Framework and architecture The designers of the Encounter game program saw an opportunity for a creative abstract framework: a layer of general role-playing game packages supporting a layer of specific Encounter packages They decided to use 3 modules, each of 2 layers cast (characters) game (events and rules of engagements) environment (areas and connections)

RPG Video Game Layering Characters Framework layer «framework package» «uses» EncounterCharacters «application package» EncounterCharacter Application layer PlayerCharacter ForeignCharacter PlayerQualityWindow Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Role-Playing Game, and Encounter Packages -- showing domain classes Framework layer GameEnvironment This is a messy diagram «framework package» Characters RolePlayingGame «framework package» «framework package» «uses» Application layer EncounterGame EncounterCharacters «application package» «application package» EncounterGame Engagement EncounterCharacter EngagementDisplay EncounterEnvironment PlayerCharacter «application package» ForeignCharacter Area EncounterAreaConnection PlayerQualityWindow ConnectionHyperlink Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

One Way to Obtain The Class Model 2. Create and/or use framework classes -- for architecture More general 3. Create design classes -- specific to this application -- to complete the class model 1. Create domain classes -- from requirements analysis Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Decompose into self-contained modules. 2. Compare with a standard architecture (e.g. Garlan and Shaw’s classification – previous lectures). Improve decomposition. Data flowing in batches between processing stations? batch sequential dataflow Processing stations waiting for data, then executing? pipe-and-filter dataflow A process supplying the needs of user processes? client-server A process only reacting to events occurring upon it? event systems An application centered on a data store? repository Arranged in layers? layered Try to develop at least two alternative architectures. One way to ... Select an Architecture 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Select an Architecture 2 One way to ... Select an Architecture 2 2. Select among the alternatives identified. 3. Add utility classes to those from requirements analysis, to accommodate the architecture selected e.g., data flow: … to control flow among the elements e.g., event systems: … to control transitions among states 4. Apply an existing framework and/or design pattern. if a helpful one can be identified 5. Partition the collection of classes into packages ideally, 4-8 (nest packages for larger applications) each package should make sense in the language of the application (e.g., “videos” OK; “bigClasses” not OK) 6. Verify high cohesion within parts; low coupling among parts -- otherwise, adjust choice of modular splits. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

A Typical Repository Architecture GUI Analysis process 1 Analysis process n Control …... …... DBMS Database Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.