Presentation is loading. Please wait.

Presentation is loading. Please wait.

INFO 355Week #41 Systems Analysis II OO Design principles INFO 355 Glenn Booker.

Similar presentations


Presentation on theme: "INFO 355Week #41 Systems Analysis II OO Design principles INFO 355 Glenn Booker."— Presentation transcript:

1 INFO 355Week #41 Systems Analysis II OO Design principles INFO 355 Glenn Booker

2 Overview  Design takes the requirements for a system and develops the high level architecture of the system, and the detailed design of each component For the former, we’ll examine the UML component diagram For the latter, we’ll expand the domain model into a design class diagram INFO 355Week #42

3 INFO 355Week #93 Component Diagrams  There’s much confusion on the difference between a component and a class  A component is a modular, deployable, and replaceable part of the system Typically has more than one class in it Is defined by its behavior & interfaces

4 INFO 355Week #94 Component Diagrams  A component may be implemented by one or more artifacts (scripts, executable files, etc.) UML 1 notation UML 2 notation

5 INFO 355Week #95 Component Diagrams  Can also denote a component with a class symbol, and a stereotype of > in front of the name  Components can contain other components  They are connected with interface notation (lollipop or ball and socket)

6 INFO 355Week #96 Component Diagrams  Components are often more a marketing concept Each component is independently purchasable and upgradeable, like parts of an entertainment system  Good as a high level design concept Keep components relatively large scale (much bigger than a DLL file), or they are a pain to manage

7 Component Diagrams  Components can also be high level structures of the system, such as web servers, app servers, etc. If this level of structure is too common and/or obvious, the diagram might not be needed Could treat subsystems as components Many systems are either client/server or Internet-based architectures INFO 355Week #47 (p. 302)

8 Design Class Diagram  OO design takes requirements (use cases) and produces design models  The design class diagram adds more detail to the domain model Adds data types for attributes Adds methods  We’ll get methods from the sequence diagram next week INFO 355Week #48

9 INFO 355Week #59 More Class Diagram Concepts  Beyond what was covered last week, there are additional concepts and corresponding notations which may be used in class diagrams  They are grouped here into: Class and Object Concepts Association Concepts Attribute Concepts

10 INFO 355Week #510 Visibility  Visibility applies to a class, its attributes, and methods  Options are public, private, and protected, but their exact meaning differs by programming language Public is designated by a + sign, and means things outside the class can see it and use it

11 INFO 355Week #511 Visibility Private is shown with a – prefix, and means that thing is only visible within that class Protected is shown with a # prefix, and means something like it can be seen by that class’ generalization hierarchy, but not outside that  By default, attributes are private; classes and methods are public

12 INFO 355Week #512 Class and Object Concepts

13 INFO 355Week #513 Abstract Classes  Abstract classes are used in implementation to show a superclass that is only used via its subclasses The abstract superclass is never instantiated into an object The abstract class is shown by putting its name in italics In Visio, check the box IsAbstract

14 INFO 355Week #514 Interface Classes  An interface is an abstract class with all abstract features A class provides an interface if it implements that interface A class requires an interface if it is dependent upon an object from that interface

15 INFO 355Week #515 Interface Classes  This is a different sense for interface than the model/view/ controller breakdown  There is a special element in Visio for interface classes  Interfaces are shown in component diagrams with a lollipop

16 INFO 355Week #516 Interface Classes  An interface class could refer to a connection to an external system Have that interface class be the gateway to that external system from anywhere within your system Also called a façade pattern

17 INFO 355Week #517 Interface Classes  Or they could be a connection to somewhere else within your system, such as an interface class Treating human interfaces as an interface objects allows data objects to send output directly to them Have the data object send output to an abstract interface class, which in turn points to the actual user interface

18 INFO 355Week #518 Generalization and Classification  Generalization is often assumed to have an implied verb phrase of ‘is a’  Beware that sometimes the intent is really classification Classification means the thing (object) is an example of the “supertype”  My dog Hajime is an example of a Black Lab; therefore, it is a classification  Show classification with an > constraint

19 INFO 355Week #519 Generalization and Classification Generalization means the thing is a subtype of a supertype – they have traits in common in the supertype, but each subtype has unique traits  A poodle is a subtype of Dog; all Dogs have common traits, but poodles have certain size and shape characteristics  Use the generalization symbol

20 INFO 355Week #520 Multiple Classification  Conceptually, it is possible for one “superclass” to have many types of classifications In such cases, it is acceptable to choose one value from each generalization hierarchy Hard to define all legal combinations  Difficult to implement in code, hence only used conceptually

21 INFO 355Week #521 Association Classes  An association class is a class which depends on the existence of an association between two other classes

22 INFO 355Week #522 Association Classes  Notice that there is no multiplicity shown on the association class line ends; it is always assumed to be 1  The association class adds a constraint: You can only have one entry (instance of the association class) for each combination of the other two classes

23 INFO 355Week #523 Association Classes  Be wary of creating association classes  Consider whether the same class could just be a normal class, or if the constraint adds meaning  Often helps clarify many-many multiplicities

24 INFO 355Week #524 Active Classes  An active class is a controller class that manages its own threads based on inputs  UML 2 has a double line symbol Check the IsActive box in Visio; it thickens the lines a little in UML 1.x  Good for an independently operating process or daemon

25 INFO 355Week #525 Object Diagrams  The class diagram represents all classes which could exist in your system  If you draw the class diagram at one moment, and only show the objects which exist at that moment, you have an object diagram

26 INFO 355Week #526 Object Diagrams  This is used to help navigate complex use cases, when it isn’t clear what objects have been created or destroyed  You could consider the object diagram like a collaboration diagram without messages

27 INFO 355Week #527 Object Diagrams  Make sure to note the full object names, Ivan:Person  Actual values for attributes can be shown

28 INFO 355Week #528 Association Concepts

29 INFO 355Week #529 Association Navigability  Now we can explicitly state whether an association can go in only one direction or another  Ask yourself if either class might need to call upon a method in the other class An Invoice might add or remove LineItem(s), but will a LineItem ever create an Invoice?

30 INFO 355Week #530 Association Navigability  If it’s a one-way association, in Visio, check the correct box in the line properties for IsNavigable  Leave the line with no arrows if it’s bidirectional Bidirectional association One-way association

31 INFO 355Week #531 Association End Labels  The ends of associations can be labeled separately  Frequently helpful for hierarchical associations

32 INFO 355Week #532 Aggregation  Aggregation is used to show when parts make up the whole of something else A Club class is made up of Member(s) A Car is made up of Part(s)  The notation for aggregation is an open diamond on the collective side of the association (Club or Car)

33 INFO 355Week #533 Aggregation  To get this line in Visio Start with a Composition line Double click on it Change the Aggregation type from Composite to Shared Edit multiplicity and line ends

34 INFO 355Week #534 Composition  A concept similar to aggregation is composition  Composition is used to show properties of a class that are strongly owned by each object The composite does not imply ALL properties of that class, just an important one The diamond is filled in for composition

35 INFO 355Week #535 Composition  For examples A Polygon is defined by three or more Point(s) in some ordered sequence A Circle has a Point which is the center of that circle Hence this example 3..* Note: the multiplicity of 1..* can be manually overwritten to 3..*

36 INFO 355Week #536 Aggregation and Composition  Aggregation doesn’t affect a class diagram much, but it’s nice to show the relationship where it applies  Composition is fairly rare, but can show critical connections among classes What do Class A and Class B have in common? They share a composition with Class C.

37 INFO 355Week #537 Qualified Associations  A qualified association can be used to refine the multiplicities of an association by specifying an attribute through which the association is made

38 INFO 355Week #538 Qualified Associations  The multiplicity of the qualified association (itemID) is always 1 The other multiplicity is based on one example of the qualified association (one itemID associates with exactly one ProductSpecification) Could express as ‘there is one ProductSpecification per itemID in the ProductCatalog’

39 INFO 355Week #539 Attribute Concepts

40 INFO 355Week #540 Static Attributes and Methods  Static means the attribute or method applies to the class, not its instances (objects)  Analogous to the C concept of static, if an attribute or method is static, its name is underlined on the class diagram I can’t find a Visio way to show this; add a stereotype of >?

41 INFO 355Week #541 Derived Attributes  In a class diagram, attributes which are derived (calculated) from other attributes can be shown if they are significant Normalization doesn’t have to apply to classes!  Put a front slash ‘/’ in front of the attribute’s name to show you are deliberately using a derived attribute

42 INFO 355Week #542 Derived Attributes  A Note box (text box with upper right corner dog-eared) can be used to show how the derived attribute is calculated (Fig 5.5) Note box

43 INFO 355Week #543 Attribute Data Types  As shown in the example on slide 35, each attribute can show its data type, using the format attributename: datatype startdate: Date  This is easy for primitive, or built-in data types; how deal with non-primitive data types?

44 INFO 355Week #544 Primitive vs. Non-Primitive Data  Recall primitive data (attribute) types are the most basic ways to represent data in a computer Boolean, Date, Number, String, Time  More elaborate data types are considered non-primitive

45 INFO 355Week #545 Attribute Types Boolean (T/F) AddressColor DateZip/Postal Code Shape Number (int or real) PhoneUPC or EAN String (Text) SSNSKU TimeMoneyEnumerated The primitive data types are in bold; others are non-primitive

46 INFO 355Week #546 Non-Primitive Data Types  Use non-primitive if any of the following guidelines apply: Data has separate sections (phone) There are operations associated with it (SSN) It needs other characteristics (start and end date, for example) It has any units (height, $, seconds) Or any other complex concept (UPC)

47 INFO 355Week #547 Non-Primitive Data Types  So a credit card number is a non-primitive data type, since it has Type of card (Visa/MC/Discover) Fixed length depending on type Validation rules based on first digit  Non-primitive data can be shown as separate conceptual classes, or just flagged as specific data types

48 INFO 355Week #548 Non-Primitive Data Types Example Class is called ProductSpecification. One attribute is called ‘id’, which is of the non-primitive data type ‘ItemID’. This is the equivalent: Format:

49 INFO 355Week #549 Attributes with Units  Things with units ($, ft., lb., etc.) need to be modeled with non-primitive data types  This helps support international- ization and conversion to other measurement systems (e.g. dollars to Euros, or English to metric units)

50 INFO 355Week #550 Non-Primitive Data Types  Non-primitive data type classes can be shown separately from the rest of the class diagram (to avoid clutter)  This is the only exception to the need for every class to be explicitly associated with at least one other class, since the association is implied

51 INFO 355Week #551 Enumeration Classes for Attributes  A class can be defined to contain only the elements of a list or enumerated attribute (p. 83)  The > stereotype is added before the class name  This is like using a class to define any other non-primitive attribute In Visio, based on the Data Type class


Download ppt "INFO 355Week #41 Systems Analysis II OO Design principles INFO 355 Glenn Booker."

Similar presentations


Ads by Google