Analysis Models, Analysis Class Diagram II PB007 Software Engineering I Bruno Rossi 31. 10. 2016 I (PB007) Analysis Class Diagrams II 31. 10. 2016 1/15 The Analysis Model is a conceptual model that captures the abstraction of a problem in modeling the business domain. The use of design patterns can increase the flexibility and reusability of the model. In modelling, there are often a set of recurring problems. For example, the model for the organizational structure of a company can be used also with other similar types of hierarchies. Therefore, there are already some prepared patterns that can be used when modelling a software system. We just see here some of them. Software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 2 / 15 Analysis Patterns - Martin Fowler Martin Fowler: Analysis Patterns - Reusable Object Models ► http://books.google.cz/books?id=4V8pZmpwmBYC&pg ► available at the library Fl, MZK ► different patterns according to the different domains Examples: Accountability, Observations and Measurements, Refering to Objects, Inventory and Accounting, Planning, Trading ► Each chapter contains several patterns that are then shown in use in some simple example and then also into more complex ones. ► Total of 65 analysis patterns and 21 auxiliary patterns Software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 3 / 15 Analysis Patterns - Accountability - Party Telephone directory: 0.* 0..1 TelephoneNumber 0..1 0.* Person 0.* 0..1 Address 0..1 0..* Company 0.* 0..1 EmailAddress 0..1 0.* Software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 4 / 15 Analysis Patterns - Accountability - Party II Many of the roles that people play can also be derived from organizational units. Party/participant is an uniform name for these roles Person r I -[> Company -[ L TelephoneNumber 0..1 0.* Address Party 0..* 0..1 0.* EmailAddress 0..1 .-,_ software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 5 / 15 Analysis Models - Organization Hierarchies OperatingUnit 1 0.* Region 1 0.* Division 1 0.* SalesOffice ► inflexible - for addition/change of organizational units, it is necessary to change big part of the model ► small reusability - different companies can vary in organizational structure oftware Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 6 / 15 Analysis Models - Organization Hierarchies II Constr.: cannot have a parent I OperatingUnit subsidiary 0.* Organization [hierarchy] 0..1 parent Constr.: parent must be a region Region Division SalesOfflce 1 Constr.: parent must be an oper.unit 1 Constr.: parent must be a region ► And what if the company has a different type of organizational structures (e.g. Sales and Production) or when they change over time? oftware Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 7/15 Analysis Models - Organization Hierarchies III OrganizationStructureType OperatingUnit 0..* OrganizationStructure subsidiary 1 1 0..* parent Organization TimePeriod software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 8/15 Analysis Models - other resources ► http://martiniowler.com/articles.html ► Gamma, Helm, Johnson, Vlissides ("Gang of Four" - GoF): Design Patterns: Elements of Reusable Object-Oriented Software, 1991-1994 ► Buschmann, Meunier, Rohnert, Sommerland, Stal: Pattern -Oriented Software Architecture: A System of Patterns ► Lubor Sešera, Aleš Mičovský, Juraj Červeň: Datové modelování v příkladech Software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 9 / 15 Relations between classes The basic relationships include: ► Generalization ► Association ► Dependency software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 10 / 15 Association The Association is a relationship between classes. ► represents long-term relationships ► this type of reference is most often reflected in the presence of an attribute of the type of the other class ► relations 1:1 correspond to one reference attribute ► relations 1:N correspond generally to an array or collection ► the direction of the association (navigability) indicates the class that will contain the attribute Software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 11 / 15 Association - Navigability The company has a relationship with more employees Company 1 ►employs Employee * The company contains a reference to a collection of employees, employed by. Employees do not have relation with company. Company 1 ►employs ^ Employee *^ The company does not have a direct link to the staff. The employee has an attribute of type company as a reference. Company ►employs Employee W Software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 12 / 15 A dependency is a relationship between two classes (client and provider), where a change in provider may force a change in the client. In other words, the client somehow depends on the provider. The importance of this dependence may be specified by different stereotypes. The most often used stereotype is use. It indicates that some of the operations of the client object use the provider as an input argument or output. Client Provider LineSegment <> Point +operation(start : Point, end : Point) ------------_> .-,_ software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 13 / 15 Finalize the analysis class diagram ► The diagram should contain the analysis classes, attributes, operations and the different relationships (inheritance, association, dependencies) ► The associations should specify names, multiplicity and navigability ► Add manager classes that will take care of the lifecycle of other classes (maintaining a list of objects, creation, search, ...). Move the appropriate responsibilities/operation Update the Use Case diagram. For each class there should be a use case that creates instances, uses, and deletes instances of the class Think about the interactions between the different class instances. Based on your class diagram, can you represent all the use cases? OPTIONAL: If you have time, think about using analytical models patterns (eg. Party or Organization Hierarchies); Upload the pdf report on the folder (Week 06). Deadline: Fri, 04.11. 23:59 « software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 14 / 15 Configuration of PDF Reports Generate PDF Content I Options j] page 5etup | Cover Page | Header/Footer | Document Info | Watermark | Details — rOptions— p Generate table of contents p Generate table of figures p Generate diagrams Image type : [sVC p Generate diagram type title |~~ Generate diagram properties p Generate diagram summary |~~ Include extra details |~~ Suppress element with blank documentation in summary table p Generate reference (file/URL) link |~~ Generate model elements/diagrams link |~~ Skip heading for empty model element section |~~ Convert multiline model heading to single line |~~ Show multiline model name |~~ Treat HTML content as HTML source |~~ Suppress details if duplicated p Table cell keep together with page Wrap : Word wrap Shape type style : |lcon T [ RTF content appearance : 11 Preserve formatting p Children (* Model-based r" Diagram-based |~~ Members r ERD Column Details \~ Properties |~~ Project management properties \~ Relationships |7 Quality information \~ References |~~ References documentation p Sub-diagrams |~~ Include sub-diagram details \~ Comments Sort by Date/Time: [Descending j \~ Tagged values P ORM Class Details p Use Case Details Generate Cancel Apply Help Reset Reset to Default Set as Default software Engineering I (PB007) Analysis Class Diagrams II 31. 10. 2016 15 / 15