Task 1 High-Level Object-Oriented Class Specification Create Initial Design Classes Designing Boundary Classes

Transcription

1 Task 1 High-Level Object-Oriented Class Specificatin This assessment task requires yu t analyse requirements and prduce a set f high-level bject-riented class specificatins fr a specific bject-riented prgramming prject. Classes are the wrk-hrses f the design effrt. They actually perfrm the real wrk f the system. The ther design elements: subsystems, packages and cllabratins simply describe hw classes are gruped r hw they interperate. Capsules are als steretyped classes, used t represent cncurrent threads f executin in real-time systems. In such cases, ther design classes are 'passive' classes, used within the executin cntext prvided by the 'active' capsules. When the designer chses nt t use a design apprach based n capsules, it is still pssible t mdel cncurrent behaviur using 'active' classes. Active classes are design classes which crdinate and drive the behaviur f the passive classes - an active class is a class whse instances are active bjects, wning their wn thread f cntrl. The prgramming prject is as fllws: An applicatin that lads and unlads cntainers nt a ship. Offladed cntainers are put n apprpriate trucks r train cars. There will be several different kinds f cntainers but at first there will be three kinds f cntainers: 1. A nrmal basic cntainer that is used fr mst shipping 2. A heavy cntainer is a kind f basic cntainer 3. A refrigerated cntainer which is a kind f heavy cntainer Any cntainer may have special prperties fr cntaining explsives Any cntainer may have special prperties fr cntaining txics Each ship has capacity that may be different. The capacity has the fllwing parts: 1. Maximum number f txic and explsive cntainers (ptinal fr a ship) 2. Maximum number f refrigerated cntainers (ptinal fr a ship) 3. Maximum number f heavy cntainers 4. Maximum number f all cntainers including basic cntainers The applicatin will read an XML file that cntains the name and capacity infrmatin f the ship t be laded and a list f cntainers including the serial number f each and type and prperties f each. When run the prgram will read the XML file and print a manifest including serial numbers and infrmatin abut each cntainer put n the ship. The crrect answer wuld be t max ut heavy, refrigerated, and txic cntainers and explsive cntainers fr a ship Create Initial Design Classes Start by creating ne r several (initial) design classes fr the analysis class given as input t this activity, and assign trace dependencies. The design classes created in this step will be refined, adjusted, split and/r merged in the subsequent steps when assigned varius "design" prperties, such as peratins, methds, and a state machine, describing hw the analysis class is designed. Depending n the type f the analysis class (bundary, entity, r cntrl) that is t be designed, there are specific strategies that can be used t create initial design classes. Designing Bundary Classes The general rule in analysis is that there will be ne bundary class fr each windw, r ne fr each frm, in the user interface. The cnsequence f this is

2 that the respnsibilities f the bundary classes can be n a fairly high level, and need then be refined and detailed in this step. The design f bundary classes depends n the user interface (r GUI) develpment tls available t the prject. Using current technlgy, it is quite cmmn that the user interface is visually cnstructed directly in the develpment tl, thereby autmatically creating user interface classes that need t be related t the design f cntrl and/r entity classes. If the GUI develpment envirnment autmatically creates the supprting classes it needs t implement the user interface, there is n need t cnsider them in design - nly design what the develpment envirnment des nt create fr yu. Additinal input t this wrk are sketches, r screen dumps frm an executable user-interface prttype, that may have been created t further specify the requirements made n the bundary classes. Bundary classes which represent the interfaces t existing systems are typically mdelled as subsystems, since they ften have cmplex internal behaviur. If the interface behaviur is simple (perhaps acting as nly a pass-thrugh t an existing API t the external system) ne may chse t represent the interface with ne r mre design classes. If this rute is chsen, use a single design class per prtcl, interface, r API, and nte special requirements abut used standards and s n in the special requirements f the class. Designing Entity Classes During analysis, entity classes represent manipulated units f infrmatin; entity bjects are ften passive and persistent. In analysis, these entity classes may have been identified and assciated with the analysis mechanism fr persistence. Perfrmance cnsideratins may frce sme re-factring f persistent classes, causing changes t the Design Mdel. Designing Cntrl Classes A cntrl bject is respnsible fr managing the flw f a use case and thus crdinates mst f its actins; cntrl bjects encapsulate lgic that is nt particularly related t user interface issues (bundary bjects), r t data engineering issues (entity bjects). This lgic is smetimes called applicatin lgic, r business lgic. Given this, at least the fllwing issues need t be taken int cnsideratin when cntrl classes are designed: Cmplexity. Simple cntrlling r crdinating behaviur can be handled by bundary and/r entity classes. As the cmplexity f the applicatin grws, hwever, significant drawbacks t this apprach surface: The use case crdinating behaviur becmes imbedded in the UI, making it mre difficult t change the system. The same UI cannt be used in different use case realizatins withut difficulty. The UI becmes burdened with additinal functinality, degrading its perfrmance. The entity bjects may becme burdened with use-case specific behaviur, reducing their generality. T avid these prblems, cntrl classes are intrduced t prvide behaviur related t crdinating flws-f-events

3 Change prbability. If the prbability f changing flws f events is lw, r the cst is negligible, the extra expense and cmplexity f additinal cntrl classes may nt be justified. Distributin and perfrmance. The need t run parts f the applicatin n different ndes r in different prcess spaces intrduces the need fr specializatin f design mdel elements. This specializatin is ften accmplished by adding cntrl bjects and distributing behaviur frm the bundary and entity classes nt the cntrl classes. In ding this, the bundary classes migrate tward prviding purely UI services, and the entity classes tward prviding purely data services, with the cntrl classes prviding the rest. Transactin management. Managing transactins is a classic crdinatin activity. When a framewrk t handle transactin management is absent, ne wuld have ne r mre transactin manager classes which wuld interact t ensure that the integrity f transactins is maintained. Identify Persistent Classes Classes which need t be able t stre their state n a permanent medium are referred t as 'persistent'. The need t stre their state may be fr permanent recrding f class infrmatin, fr back-up in case f system failure, r fr exchange f infrmatin. A persistent class may have bth persistent and transient instances; labelling a class 'persistent' means merely that sme instances f the class may need t be persistent. Example The analysis mechanism fr persistency might be realized by ne f the fllwing design mechanisms: In-memry strage Flash card Binary file Database Management System (DBMS) depending n what is required by the class. Nte that persistent bjects may nt nly be derived frm entity classes; persistent bjects may als be needed t handle nn-functinal requirements in general. Examples are persistent bjects needed t maintain infrmatin relevant t prcess cntrl, r t maintain state infrmatin between transactins. Define Class Visibility Fr each class, determine the class visibility within the package in which it resides. A 'public' class may be referenced utside the cntaining package. A 'private' class (r ne whse visibility is 'implementatin') may nly be referenced by classes within the same package. Define Operatins Identify Operatins T identify Operatins n design classes: Study the respnsibilities f each crrespnding analysis class, creating an peratin fr each respnsibility. Use the descriptin f the respnsibility as the initial descriptin f the peratin. Studying the use-case realizatins in the class helps t see hw the peratins are used by the use-case realizatins. Extend the peratins,

4 ne use-case realizatin at the time, refining the peratins, their descriptins, return types and parameters. Each use-case realizatin's requirements as regards classes are textually described in the Flw f Events f the use-case realizatin. Study the use case Special Requirements, t make sure that yu d nt miss implicit requirements n the peratin that might be stated there. Operatins are required t supprt the messages that appear n sequence diagrams because scripts; messages (temprary message specificatins) which have nt yet been assigned t peratins describe the behaviur the class is expected t perfrm. An example sequence diagram is shwn belw: Messages frm the basis fr identifying peratins. Use-case realizatins cannt prvide enugh infrmatin t identify all peratins. T find the remaining peratins, cnsider the fllwing: Is there a way t initialize a new instance f the class, including cnnecting it t instances f ther classes t which it is assciated? Is there a need t test t see if tw instances f the class are 'equal'? Is there a need t create a cpy f a class instance? Are any peratins required n the class by mechanisms which they use (example: a 'garbage cllectin' mechanism may require that an bject be able t drp all f its references t all ther bjects in rder fr unused resurces t be freed)? D nt define peratins which merely get and set the values f public attributes (see Define Attributes and Assciatins); these are generally generated by cde generatin facilities and d nt need t be explicitly defined. Name and Describe the Operatins Fr each peratin, yu shuld define the fllwing: The peratin name. The name shuld be shrt and descriptive f the result the peratin achieves. The names f peratins shuld fllw the syntax f the implementatin language. Example: find_lcatin wuld be

5 acceptable fr C++ r Visual Basic, but nt fr Smalltalk (in which underscres are nt used); a better name fr all wuld be findlcatin. Avid names that imply hw the peratin is perfrmed (example: Emplyee.wages() is better than Emplyee.calculateWages(), since the latter implies a calculatin is perfrmed. The peratin may simply return a value in a database). The name f an peratin shuld clearly shw its purpse. Avid unspecific names, such as getdata, that are nt descriptive abut the result they return. Use a name that shws exactly what is expected, such as getaddress. Better yet, simply let the peratin name be the name f the prperty which is returned r set; if it has a parameter, it sets the prperty, if it has n parameter it gets the prperty. Example: the peratin address returns the address f a Custmer, while address(astring) sets r changes the address f the Custmer. The 'get' and 'set' nature f the peratin are implicit frm the signature f the peratin. Operatins that are cnceptually the same shuld have the same name even if different classes define them, they are implemented in entirely different ways, r they have a different number f parameters. An peratin that creates an bject, fr example, shuld have the same name in all classes. If peratins in several classes have the same signature, the peratin must return the same kind f result, apprpriate fr the receiver bject. This is an example f the cncept f plymrphism, which says that different bjects shuld respnd t the same message in similar ways. Example: the peratin name shuld return the name f the bject, regardless hw the name is stred r derived. Fllwing this principle makes the mdel easier t understand. The return type. The return type shuld be the class f bject that is returned by the peratin. A shrt descriptin. As meaningful as we try t make it, the name f the peratin is ften nly vaguely useful in trying t understand what the peratin des. Give the peratin a shrt descriptin cnsisting f a cuple f sentences, written frm the peratin user's perspective. The parameters. Fr each parameter, create a shrt descriptive name, decide n its class, and give it a brief descriptin. As yu specify parameters, remember that fewer parameters mean better reusability. A small number f parameters makes the peratin easier t understand and hence there is a higher likelihd f finding similar peratins. Yu may need t divide an peratin with many parameters int several peratins. The peratin must be understandable t thse wh want t use it. The brief descriptin shuld include the fllwing: The meaning f the parameters (if nt apparent frm their names). Whether the parameter is passed by value r by reference Parameters which must have values supplied

6 Parameters which can be ptinal, and their default values if n value is prvided Valid ranges fr parameters (if applicable) What is dne in the peratin. Which by reference parameters are changed by the peratin. Once yu have defined the peratins, cmplete the sequence diagrams with infrmatin abut which peratins are invked fr each message. Define Operatin Visibility Fr each peratin, identify the exprt visibility f the peratin. The fllwing chices exist: Public: the peratin is visible t mdel elements ther than the class itself. Implementatin: the peratin is visible nly within t the class itself. Prtected: the peratin is visible nly t the class itself, t its subclasses, r t friends f the class (language dependent) Private: the peratin is nly visible t the class itself and t friends f the class Chse the mst restricted visibility pssible which can still accmplish the bjectives f the peratin. In rder t d this, lk at the sequence diagrams, and fr each message determine whether the message is cming frm a class utside the receiver's package (requires public visibility), frm inside the package (requires implementatin visibility), frm a subclass (requires prtected visibility) r frm the class itself r a friend (requires private visibility). Define Class Operatins Fr the mst part, peratins are 'instance' peratins, that is, they are perfrmed n instances f the class. In sme cases, hwever, an peratin applies t all instances f the class, and thus is a class-scpe peratin. The 'class' peratin receiver is actually an instance f a metaclass, the descriptin f the class itself, rather than any specific instance f the class. Examples f class peratins include messages which create (instantiate) new instances, which return allinstances f a class, and s n. T dente a class-scpe peratin, the peratin string is underlined. Define Methds A methd specifies the implementatin f an peratin. In many cases, methds are implemented directly in the prgramming language, in cases where the behaviur required by the peratin is sufficiently defined by the peratin name, descriptin and parameters. Where the implementatin f an peratin requires use f a specific algrithm, r requires mre infrmatin than is presented in the peratin's descriptin, a separate methd descriptin is required. The methd describes hw the peratin wrks, nt just what it des. The methd, if described, shuld discuss: Hw peratins are t be implemented. Hw attributes are t be implemented and used t implement peratins. Hw relatinships are t be implemented and used t implement peratins. The requirements will naturally vary frm case t case. Hwever, the methd specificatins fr a class shuld always state: What is t be dne accrding t the requirements?

7 What ther bjects and their peratins are t be used? Mre specific requirements may cncern: Hw parameters are t be implemented. Any special algrithms t be used. Sequence diagrams are an imprtant surce fr this. Frm these it is clear what peratins are used in ther bjects when an peratin is perfrmed. A specificatin f what peratins are t be used in ther bjects is necessary fr the full implementatin f an peratin. The prductin f a cmplete methd specificatin thus requires that yu identify the peratins fr the bjects invlved and inspect the crrespnding sequence diagrams. Define States Fr sme peratins, the behaviur f the peratin depends upn the state the receiver bject is in. A state machine is a tl fr describing the states the bject can assume and the events that cause the bject t mve frm ne state t anther. State machines are mst useful fr describing active classes. An example f a simple state machine is shwn belw: A simple statechart diagram fr a Fuel Dispenser Each state transitin event can be assciated with an peratin. Depending n the bject's state, the peratin may have a different behavir; the transitin events describe hw this ccurs. The methd descriptin fr the assciated peratin shuld be updated with the state-specific infrmatin, indicating, fr each relevant state, what the peratin shuld d. States are ften represented using attributes; the statechart diagrams serve as input int the attribute identificatin step. Define Attributes During the definitin f methds and the identificatin f states, attributes needed by the class and its peratins are identified. Attributes prvide infrmatin strage fr the class instance, and are ften used t represent the state f the class instance. Any infrmatin the class itself maintains is dne thrugh its attributes. Fr each attribute, define the fllwing:

8 its name, which shuld fllw the naming cnventins f bth the implementatin language and the prject; its type, which will be an elementary data type supprted by the implementatin language; its default r initial value, t which it is initialized when new instances f the class are created its visibility, which will take ne f the fllwing values: Public: the attribute is visible bth inside and utside the package cntaining the class. Prtected: the attribute is visible nly t the class itself, t its subclasses, r t friends f the class (language dependent) Private: the attribute is nly visible t the class itself and t friends f the class. Implementatin: the attribute is visible nly t the class itself. fr persistent classes, whether the attribute is persistent (the default) r transient. Even thugh the class itself may be persistent, nt all attributes f the class need t be persistent. Check t make sure all attributes are needed. Attributes shuld be justified - it is easy fr attributes t be added early in the prcess and survive lng after they are n lnger needed due t shrtsightedness. Extra attributes, multiplied by thusands r millins f instances, can have a large effect n the perfrmance and strage requirements f the system. Define Dependencies Fr each case where the cmmunicatin between bjects is required, ask the fllwing questins: Is the reference t the receiver passed as an parameter t the peratin? If s, establish a dependency between the sender and receiver classes in a class diagram cntaining the tw classes. In additin, if the cllabratin diagram frmat fr interactins is used, qualify the link visibility, setting it t 'parameter'. Is the receiver a 'glbal'? If s, establish a dependency between the sender and receiver classes in a class diagram cntaining the tw classes. In additin, if the cllabratin diagram frmat fr interactins is used, qualify the link visibility, setting it t 'glbal'. Is the receiver a temprary bject created and destryed during the peratin itself? If s, establish a dependency between the sender and receiver classes in a class diagram cntaining the tw classes. In additin, if the cllabratin diagram frmat fr interactins is used, qualify the link visibility, setting it t 'lcal'. Nte that links mdelled in this way are transient links, existing nly fr a limited duratin, in the specific cntext f the cllabratin - in that sense, they are instances f the assciatin rle in the cllabratin. Hwever, the relatinship in a class mdel (i.e. independent f cntext) shuld be, as stated abve, a dependency. As [RUM98] states, in the definitin f transient link: "It is pssible t mdel all such links as assciatins, but then the cnditins n the assciatins must be stated very bradly, and they lse much f their precisin in cnstraining cmbinatins f bjects". In this situatin, the mdelling f a dependency is less imprtant than the mdelling f the relatinship in the

9 cllabratin, because the dependency des nt describe the relatinship cmpletely, nly that it exists. Define Assciatins Assciatins prvide the mechanism fr bjects t cmmunicate with ne anther. They prvide bjects with a "cnduit" alng which messages can flw. They als dcument the dependencies between classes, highlighting fr us that changes in ne class may be felt amng many ther classes. Examine the methd descriptins fr each peratin t understand hw instances f the class cmmunicate and cllabrates with ther bjects. In rder t send a message t anther bject, an bject must have a reference t the receiver f the message. A cllabratin diagram (an alternative representatin f a sequence diagram) will shw bject cmmunicatin in terms f links, as shwn belw: Define Assciatins and Aggregatins The remaining messages will use either assciatin r aggregatin t specify the relatinship between instances f tw classes which cmmunicate. Fr bth f these assciatins, set the link visibility t 'field' in cllabratin diagrams. Other tasks include: Establish the navigability f assciatins and aggregatins. Yu d this by cnsidering what navigabilities are required n their link instantiatins in the interactin diagrams. Because navigability is true by default, yu nly need t find assciatins (and aggregatins) where all ppsite link rles

10 f all bjects f a class in the assciatin d nt require navigability. In thse cases, set the navigability t false n the rle f the class. If there are attributes n the assciatin itself (represented by "assciatin classes"), create a design class t represent the 'assciatin class', with the apprpriate attributes. Interpse this class between the ther tw classes, and by establishing assciatins with apprpriate multiplicity between the assciatin class and the ther tw classes. Specify if "assciatin ends" shuld be rdered r nt; this shuld be the case if the bjects assciated with an bject at the ther end f the assciatin have an rdering that must be preserved. If the assciated (r aggregated) class is nly referenced by the current class, and cnsider whether the class shuld be nested. Advantages f nesting classes include faster messaging and a simpler design mdel; disadvantages include having the space fr the nested class statically allcated regardless whether there instances f the nested class, lack f bject identity separate frm the enclsing class, and inability t reference nested class instances frm utside the enclsing class. Assciatins and aggregatins are best defined in a class diagram which depicts the assciated classes. The class diagram shuld be wned by the package which cntains the assciated classes. An example class diagram, depicting assciatins and aggregatins, is shwn belw: Example Class Diagram, shwing Assciatins, Aggregatins, and Generalizatins between Classes. Handling Subscribe-Assciatins between Analysis Classes Subscribe-assciatins between analysis classes are used t identify event dependencies between classes. In the Design Mdel we must explicitly handle these event dependencies, either using available event-handler framewrks, r by designing and building ur wn event-handler framewrk. In sme

11 prgramming languages such as Visual Basic this is straightfrward by declaring, raising, and handling the crrespnding events. In ther languages yu might have t use sme additinal library f reusable functins t handle subscriptins and events; if the functinality can't be purchased, it will need t be designed and built. Define Generalizatins Classes may be rganized int a generalizatin hierarchy t reflect cmmn behaviur and cmmn structure. A cmmn super-class can be defined, frm which sub-classes can inherit bth behaviur and structure. Generalizatin is a ntatinal cnvenience which allws us t define cmmn structure and behaviur in ne place and re-use it where we find repeated behaviur and structure. When generalizatin is fund, create a cmmn super-class t cntain the cmmn attributes, assciatins, aggregatins, and peratins. Remve the cmmn behaviur frm the classes which are t becme sub-classes f the cmmn super-class. Define a generalizatin relatinship frm the sub-class t the super-class. Handle Nn-Functinal Requirements in General The Design Classes shuld be refined t handle general nn-functinal requirements specific t the prject. An imprtant input t this step are the nnfunctinal requirements n an analysis class that may already be stated in its special requirements and respnsibilities. Such requirements are ften specified in terms f what architectural (analysis) mechanisms are needed t realize the class; in this step the class is then refined t incrprate the design mechanisms crrespnding t these analysis mechanisms. Fr each design mechanism needed, qualify as many characteristics as pssible, giving ranges where apprpriate. There can be several general design guidelines and mechanisms that need t be taken int cnsideratin when classes are designed: Hw t use existing prducts and cmpnents, Hw t adapt t the prgramming language, Hw t distribute bjects, Hw t achieve acceptable perfrmance, Hw t achieve certain security levels, Hw t handle errrs, Etc. Evaluate Yur Results Yu shuld check the design mdel at this stage t verify that yur wrk is headed in the right directin. After finalizing yur requirements, yur team shall develp a design that fully satisfies the requirements fr yur applicatin. This deliverable will cnsist f tw primary cmpnents: a design specificatin (cnsisting f a high-level architectural design and mdule specificatins) and an integratin test plan. Yu may wish t d an bject-riented design and adhere t the Object Mdelling Technique. In this case, yur design specificatin shuld include the fllwing three mdels: the bject mdel, which cnsists f bject diagrams; the dynamic mdel, which cnsists f event traces and state diagrams; and the functinal mdel, which cnsists f data flw diagrams. The design shuld

12 describe all system level bjects/tasks, peratins, the relatinships between thse bjects/tasks, and external interactin with the envirnment as well as bject class specificatins that further detail the bject design. In cnjunctin with this bject-riented design, yur team must develp an integratin test plan cvering the interfaces between specified mdules and/r bjects. The integratin test plan must cver all interactins between mdules/bjects by applying functinal test heuristics (black bx) t each mdule/class interface in the design specificatin and develping a test plan fr each interactin between mdules and/r bjects. Yur dcument must specify the crrespndence between the requirements specificatin and yur design. Yu may shw this crrespndence any way yu feel is apprpriate (e.g., make ntatins thrughut yur dcument r using a table that crss-references paragraph numbers). Develping the sftware design will undubtedly reveal inadequacies in previus dcuments. Please nte these prblems and what was dne t slve them. Dn't frget t include yur meeting minutes and perfrmance appraisals with yur dcument; refer t the syllabus fr the cmplete check-list f what has t be turned in. As befre, make sure that yu pst yur design dcument and yur meeting minutes t yur team web page. Deliverable Objectives/Quality Keep in mind that key bjectives f a design dcument are t: Develp a cherent representatin f sftware that will satisfy requirements Identify inadequacies in requirements Decmpse the system int sub-systems that prvide related sets f services Establish a framewrk fr sub-system cntrl and cmmunicatin Specify mdules that can be assigned as cding respnsibilities Dcument design decisins and ratinale Prvide a reference tl readable by develpers, testers, and maintainers Prvide a basis fr integratin and testing In additin, keep in mind that a design dcument shuld exhibit the fllwing qualities: Cmplete: everything that is essential is described Rigrus: expressed in a well-defined ntatin Cnsistent: n mismatched interfaces Unifrm: the entire dcument is at same level f detail Mdifiable: this dcument will change just like all the thers Desensitized t change: hides implementatin details and secrets Cnfirmable, verifiable and testable: yu can tell when yu've met the design Dcument Cntents Intrductin Expand yur intrductin t discuss yur specific appraches t the design f the system and the rganizatin f this dcument. This descriptin is essentially just an updated versin f the intrductin yu included in yur previus deliverable. Understanding

13 Expand the understanding sectin f yur previus dcument. Make sure t add descriptins f what steps r actins yu tk t understand each technlgy studied during this phase. If yu make changes t this sectin, add text describing why the change was necessary, and why it mre accurately reflects yur new understanding. This sectin need nt be different if yur understanding hasn't changed. Prject Plan This will be an iterative expansin f yur previus submissin. Expand yur prject plan t represent hw yu have accmplished the wrk s far. Reassess the prject risks. Expand yur task netwrk r wrk breakdwn structure t include the effrt expended t cmplete this task. Based n the wrk yu have dne, revise yur estimates n hw much yur team can accmplish and deliver. If yu make changes, add text describing why the change was necessary r why it will imprve the ability f yur team t accmplish the wrk yu have prpsed. Design Specificatin Architecture Overview Architectural Style What style f architecture did yu adpt? Prvide a reference t a defining dcument. System Architecture Overview This is the place fr yur "ne great diagram" that shws hw yur system is built. Yu might want t use mre than ne diagram, t shw, e.g., sme different abstractins f the design (such as a data flw view, a layers f abstractin view, an bject view, r an OS prcess view) Subsystem Narrative What each subsystem means Majr limitatins n the current design Mdules/Objects Specificatin List f Mdules/Objects within yur system Fr each mdule/bject, prvide a Mdule Specificatin Name Definitin/Purpse - what it is/des Narrative/Cmment - hw it wrks What are the interfaces r APIs? E.g., using Java terminlgy public private prtected Data - What state des it keep, what variables? Access - Wh has access t the mdule/bject/data? Hw des it fit int the inheritance/with/uses hierarchy? Cnstraints - what cnstraints are there fr this bject/mdule? Cardinality - Hw many will there be?

14 Other useful diagrams : Uses, is-cmpsed-f, Design class diagrams, State transitin diagrams, API's Class-categry diagrams, r ther useful diagrams Integratin Test Plan Includes an integratin test plan capable f demnstrating that the design meets the functinality specified in the requirements. Test cases shuld cver each mdule/bject and mdule/bject interactin specified in the design. Yu shuld cnsider each mdule/bject as a subsystem and apply functinal (black bx) test heuristics (such as input/utput cverage and errr/exceptin cverage) t the parameters identified in each peratin in the interface. In additin, yu shuld develp a test case fr each mdule/bject interactin. NOTE: if desired, the test cases can be gruped with the design entity t which they apply, therwise a crss reference listing f sme srt shuld be prvided. Fr each test Test ID Purpse f Test Item(s) being tested Input specificatin Output specificatin Expected Results r Test Oracle Mechanism Test envirnmental needs r special test prcedures Initial Demnstratin Plan What and hw will yu demnstrate? Tracking and Cntrl Mechanisms Cnfiguratin Management: hw will yur mdules/bjects be managed? file structure, sub-directries, Makefiles, etc. persistent data Requirements Crss Reference: what mdules/bjects satisfy what requirements? a table mapping requirement t mdule/bject make sure it is cmplete and cnsistent. Mdificatins t Prir Dcuments Requirements If any requirements changed, were added r deleted, this is the place t make this explicit. Highlight why the requirement was changed/added/deleted and by whm (custmer, develper, etc.). Make sure yur requirements meet the bjectives f cmpleteness, understandability, utility, unambiguity, and cnsistency. If yur requirements have nt changed, then this sectin shuld be identical t what yu submitted earlier. Glssary Defines any terms used in the specificatins abve. This prtin f the dcument may be written as an extensin t the glssary submitted with the requirements, r may be a separate dcument that nly defines terms lcal t the design phase. Additinal Dcumentatin This sectin is reserved fr any additinal dcumentatin develped during this phase f the prject. Specifically, if during the curse f develping the architecture yur understanding f the varius technlgies invlved in the

15 prject changed, r yu discvered items that were nt dcumented but which are imprtant, include that infrmatin here. Als list here the majr backgrund surces that yu used during this phase r any that yu plan t use during the remainder f the prject. This includes references t similar systems and/r prcedures. Design Presentatins/Reviews. See the syllabus fr dates. Each team shuld prepare a 15 minute presentatin, after which we will allw up t 5 minutes f questins. Prepare yur presentatin apprpriately. Yur presentatin shuld include the fllwing: Sme cntext fr yur prject (brief!); Current state f yur prject plan; Highlights f yur design including an verview f yur architecture (this shuld cmprise the bulk f yur presentatin) ne r mre key mdule/bject specificatins; Mdificatins t yur requirements that arse as a result f yur design prcess; Overview f yur integratin test plan. Nte: Include the cntents f the Attachment A checkpints list fr each class specificatin.

16 Attachment A - Class Design Checkpints General The name f the class clearly reflects the rle it plays. The descriptin f the class clearly cnveys the purpse f the class. The class represents a single well-defined abstractin. The class's attributes and peratins are all essential t fulfilling the respnsibilities f the class. Each class represents a small, cnsistent and unique set f respnsibilities. The respnsibilities f the class are well-defined, clearly stated, and clearly related t the purpse f the class. Each class is relatively self-cntained, and is lsely cupled t ther classes. The respnsibilities f the class are at a cnsistent level f abstractin (i.e. high-level (applicatin-level) and lw-level (implementatin-level) respnsibilities are nt mixed). Classes in the same inheritance hierarchy pssess unique class attributes, peratins and relatinships (i.e. they inherit all cmmn attributes, peratins and relatinships). The cmplete life-cycle f an instance f the class is accunted fr. Each bject is created, used, and remved by ne r mre use-case realizatins. The class satisfies the behaviural requirements established by the use-case realizatins. All requirements n the class in the requirement specificatin are addressed. The demands n the class (as reflected in the class descriptin and by the bjects in sequence diagrams) are cnsistent with the class's state machine. All respnsibilities f the class are related, such that it is nt pssible fr the class t exist in a system where sme f its respnsibilities are used, but nt thers. N tw classes have essentially the same purpse. Generalizatin/Specializatin The generalizatin hierarchy is balanced, such that there are n classes fr which the hierarchy is unusually flat r deep. Obvius cmmnality has been reflected in the inheritance hierarchy. There are n superclasses which appear t be merges f the attributes f the subclasses. There are n intermediate abstract classes in the inheritance hierarchy with rthgnal prperties, examples f which include duplicated subclasses n bth sides f an inheritance tree. Inheritance is used t capture cmmn design abstractins, nt primarily fr implementatin cnsideratins, i.e. t reuse bits f cde r class structure. Naming Cnventins Class names indicate purpse.

17 Operatins Attributes Class names fllw the naming cnventins frm the design guidelines. The name f each peratin is descriptive and understandable. The state machine and the peratins are cnsistent. The state machine and peratins cmpletely describe the behavir f the class. The parameters f each peratin are crrect in terms f bth number, name and type. Implementatin specificatins fr each peratin, where defined, are crrect. Operatin signatures cnfrm t the standards f the target prgramming language. Each peratin is used by at least ne use-case realizatin. All relatinships f the class are required t supprt sme peratin f the class. Each attribute represents a single cnceptual thing. The name f each attribute is descriptive, and crrectly cnveys the infrmatin it stres. Relatinships The rle names f aggregatins and assciatins describe the relatinship between the assciating and assciated classes. The multiplicities f the relatinships are crrect. State Machines The state machine is as simple as pssible while still expressing the required behaviur. The state machine des nt cntain any superfluus states r transitins. The state machine has a clear cntext. All referenced bjects are visible t the enclsing bject. The state machine is efficient, and carries ut its behaviur with an ptimal balance f time and resurces as defined by the actins it dispatches. The state machine is understandable. The state and transitin names are understandable in the cntext f the dmain f the system. The state names indicate what is being waited fr r what is happening, rather than what has happened. The state and transitin names are unique within the state machine (althugh nt a strict requirements, it aids in debugging t enfrce unique names). Lgical grupings f states are cntained in cmpsite states. Cmpsite states have been used effectively t reduce cmplexity? Transitin labels reflect the underlying cause f the transitin.

18 There are n cde fragments n state transitins which are mre than 25 lines f detail cde; instead, functins have been used effectively t reduce transitin cde cmplexity. State machine nesting has been examined t ensure that nesting depth is nt t deep t be understandable; ne r tw levels f substates are usually sufficient fr mst cmplex behaviurs. Active classes have been used instead f cncurrent substates; active classes are nearly always a better alternative and mre understandable than cncurrent substates. Errr r maintenance states have been accunted fr. Substates have been used instead f extended state variables; there is n evidence f transitin guard cnditins testing several variables t determine which t state the transitin shuld ccur. The state machine des nt resemble a flw chart. The state machine des nt appear t have been verly decmpsed, cnsisting f nested state machines with a single substate. In cases where the nested sub-state is a placehlder fr future design wrk r subclassing, this may be temprarily acceptable prviding that the chice has been a cnscius ne.

19 Observatin Checklist Observatin Criteria S NS Analysed behaviur scenaris and the prepared dcumentatin, accrding t standards Identified classes, bjects and abstract data types, accrding t requirements Prepared class, bject, mdule and prcess diagrams, accrding t specificatins Analysed data requirements and iterated data flws Prepared state-transitin diagrams, accrding t standards Imprved the abstract data types and specificatins Reviewed the functinal requirements, assign respnsibilities and update class structures Specified the interface and class cmmunicatin requirements Prepared the interactin diagrams, accrding t standards Reviewed the current bject mdel, class functinality and data transfrmatin Identified and develped class relatinships, pririties, and the inheritance hierarchy Reviewed the class-service requirements and initial test criteria Identified bject prcesses and reuse classes Dcumented the mdel and frward it t the apprpriate persn